Internet Info 1993

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-chang-iimc-proxy-02.txt < prev next >

Wrap

Text File | 1993-06-07 | 165KB | 3,723 lines

INTERNET DRAFT Expires November 29, 1993 ISO/CCITT and Internet Management Coexistence (IIMC): ISO/CCITT to Internet Management Proxy (IIMCPROXY) Draft 2 May 26, 1993 April Chang (Editor) NetLabs, Inc. 4920 El Camino Real Los Altos, CA 94022 april@netlabs.com Status of this Memo This document provides information to the network and systems management community. This document is intended as a contribution to ongoing work in the area of multi-protocol management coexistence and interworking. This document is part of a package; see also [IIMCOMIBTRANS] [IIMCIMIBTRANS] [IIMCMIB- II] and [IIMCSEC]. Distribution of this document is unlimited. Comments should be sent to the Network Management Forum IIMC working group (iimc@thumper.bellcore.com). This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, munnari.oz.au to learn the current status of any Internet Draft. Chang Expires November 29, 1993 Page i Draft ISO/CCITT to Internet Management Proxy 5/26/93 Abstract This document is intended to facilitate the use of the ISO/CCITT Common Management Information Protocol (CMIP) for integrated management of networks via proxy management of TCP/IP networks that are managed using Simple Network Management Protocol (SNMP). This document describes an ISO/CCITT to Internet "proxy" which allows interworking between CMIP-based managers and SNMP-based agents. The proxy emulates CMIS service requests by mapping between corresponding ISO/CCITT GDMO and Internet MIB definitions, and generating SNMP message(s) needed to emulate the service. The proxy also emulates CMIS service responses and notifications by converting incoming SNMP response and trap message(s) in a similar fashion. Thus, the proxy appears as a CMIP-based agent to the manager, and as an SNMP-based manager to the agent. The proxy depends on the availability of corresponding MIB definitions translated as described in [IIMCIMIBTRANS]. Table of Contents Status of this Memo ......................................i Abstract ..............................................ii Table of Contents ........................................ii Revision History .........................................iv 1 Introduction ..........................................1 1.1 Problem Statement ...................................1 1.2 Overview of IIMC ....................................1 1.3 MIB Translation Procedures ..........................2 1.4 Native Management Model .............................3 1.5 Proxy Management Model ..............................4 1.6 Scope of this Document ..............................5 1.7 Terms and Conventions ...............................8 2 ISO/Internet Proxy Configuration ......................10 2.1 ISO/Internet Proxy Containment Tree .................10 2.2 System Objects ......................................11 2.3 Translated MIB Schema Information ...................11 2.4 IIMC Party MIB Objects ..............................13 2.5 IIMC Proxy MIB Objects ..............................13 2.6 OMNIPoint 1 Capability Object .......................14 2.7 MIB Usage ...........................................15 2.8 Retained Information ................................16 3 Elements of CMIS Service Emulation ....................16 3.1 Association Service .................................16 3.2 Object Selection - Scoping and Filtering ............17 3.3 Management Operation Services .......................18 3.4 Synchronization .....................................21 3.5 M-GET Service .......................................22 3.6 M-CANCEL-GET Service ................................22 3.7 M-SET Service .......................................23 3.8 M-ACTION Service ....................................24 3.9 M-CREATE Service ....................................24 3.10 M-DELETE Service ...................................26 Chang Expires November 29, 1993 Page Draft ISO/CCITT to Internet Management Proxy 5/26/93 3.11 Management Notification Services ...................27 4 Common Procedures For CMISE Service Emulation .........28 4.1 Verifying Existence Of An Object Instance ...........28 4.2 Translating Timestamps ..............................28 4.3 Derivation of SNMP Request Parameters ...............29 4.4 Derivation Of CMIS Parameters .......................30 5 Error Message Translation .............................35 5.1 Translating SNMP Error Messages .....................35 5.2 CMIS Processing Failure .............................38 6 ISO/CCITT Systems Management Functions ................39 6.1 Event Report Management Function ....................39 6.2 Log Control Function ................................40 6.3 Scope of the EFD and Log ............................40 7 ISO/CCITT-Internet Proxy MIB ..........................41 7.1 Proxy MIB GDMO Templates ............................41 7.2 Proxy MIB ASN.1 Module ..............................46 8 Conformance Requirements ..............................48 8.1 Management Communication Requirements ...............48 8.2 Management Function Requirements ....................48 8.3 Management Information Requirements .................48 8.4 Service Emulation Requirements ......................49 9 Acknowledgments .......................................50 References ..............................................52 Appendix A (Normative) Managed Object Conformance Statements (MOCS) ........55 Appendix B (Informative) Example Operation ...................................56 Chang Expires November 29, 1993 Page i Draft ISO/CCITT to Internet Management Proxy 5/26/93 Revision History Draft 0 - October 9, 1992 Initial draft of this document. Draft 1 - March 28, 1993 Previous draft of this document (replaced Draft 0). Draft 2 - May 26, 1993 Current draft of this document (replaces Draft 1). Major Changes Since Last Revision 1. Revised Naming to have multiple system instances, but without constraining what system is bound to. 2. Modified the cmipsnmpProxyAgent object definition. 3. Deleted all system management function subsections except those for Event Report Management and Log Control. Defined the behaviour of EFD and Log. 4. Reorganized Proxy MIB GDMO and ASN.1 module sections. 5. Modified System Management Function requirements to include only optional support of AOM221 and AOM231. 6. Added requirements for mandatory support of ISO DMI System, translated MIB2 internetSystem, and optional support of the OMNIPoint 1 capabilityObject. 7. Modified minimum CMIP requirement to be AOM12, but minimum CMISE User requirement to be Kernel + Scoped Get. 8. Added security defaults as a new object contained by the cmipsnmpProxyAgent object class. Outstanding Issues 1. Need to specify the semantics of the operational and usage state attributes in "remote system" objects. 2. No "stateful" optimizations have been proposed. 3. Refer to [IIMCIMIBTRANS] for outstanding issue regarding translation of conceptual tables; that proposal would also impact this IIMCPROXY specification. Chang Expires November 29, 1993 Page Draft ISO/CCITT to Internet Management Proxy 5/26/93 1 Introduction This section provides an overview of ISO/CCITT and Internet Management Coexistence (IIMC) activities, insight into the problem being addressed by IIMC, and a brief introduction to the strategy adopted by IIMC: use of translated MIBs in either a proxy or native implementation. The section concludes by describing the scope of this document, and terms and conventions used by this document. 1.1 Problem Statement The need for enterprise network management has been addressed by development of network management standards within various communities, most notably the ISO/CCITT and Internet communities. - The ISO/CCITT community developed the Common Management Information Protocol (CMIP) [ISO9596-1], and related SMI documents [ISO10165-1,2,4]. - The Internet community developed the Simple Network Management Protocol (SNMP) [RFC1157], and its successor, SNMPv2 [RFC1448]. The Internet SMI is defined in [RFC1155] and [RFC1442]. These standards share a nearly common management model, but diverge due to differing management philosophies. Although functionally similar, the Internet and ISO/CCITT protocols and SMIs differ in terms of their complexity and specific operations. Business requirements for end-to-end enterprise management include the need to integrate the management of components accessed by ISO/CCITT management, Internet management, and proprietary management mechanisms in a manner which presents a unified view of the network, despite protocol and SMI differences. For example, many telecommunications and computer vendors, represented by organizations such as the Network Management Forum (NMF), and the U.S. government, as specified in the Government Network Management Profile (GNMP), have based their enterprise management model on the ISO/CCITT management model. These organizations are particularly interested in integrated management of devices that use the Internet management. This interest is primarily due to the widespread commercial implementation and use of such devices, especially devices that use the Internet TCP/IP protocol suite. 1.2 Overview of IIMC This document is part of a package of ISO/CCITT and Internet Management Coexistence (IIMC) drafts. Documents included in this package are: Chang Expires November 29, 1993 Page 1 Draft ISO/CCITT to Internet Management Proxy 5/26/93 [IIMCIMIBTRANS] Translation of Internet MIBs to ISO/CCITT GDMO MIBs [IIMCOMIBTRANS] Translation of ISO/CCITT GDMO MIBs to Internet MIBs [IIMCMIB-II] Translation of Internet MIB-II (RFC1213) to ISO/CCITT GDMO MIB [IIMCPROXY] ISO/CCITT to Internet Management Proxy [IIMCSEC] ISO/CCITT to Internet Management Security These documents together comprise a package aimed at integrating ISO/CCITT-based and Internet-based management systems. These documents represent coexistence and interworking efforts underway within the IIMC working group, chartered under the auspices of the Network Management Forum Architecture Integration ISO/Internet (AIII) technical team. The IIMC intends to address the problem that end-to-end management requires an integrated, unified view of the managed network, despite differences in management protocol and information structure. Integrated management can be facilitated by the development of "proxy" mechanisms which translate between functionally equivalent service, protocol, and SMI differences to create this unified view. MIB translation procedures can be used to support proxy management, as well as to take advantage of existing MIB definition and avoid duplication of effort. In this way, commercial investment in both ISO/CCITT and Internet-based management technologies can be preserved through deployment of common methods and tools which support integration. This overall strategy was outlined in a joint publication developed by the NM Forum and X/Open entitled "ISO/CCITT and Internet Management: Coexistence and Interworking Strategy" [NMFTR107]. The documents included in the IIMC package are the next level of detailed specifications which implement several of the methodologies identified in the strategy. 1.3 MIB Translation Procedures The foundation of IIMC is provided by a pair of Management Information Base (MIB) translation procedures. - [IIMCIMIBTRANS] specifies translation procedures for converting MIBs from Internet MIB macro format into ISO/CCITT GDMO template format. - [IIMCOMIBTRANS] specifies translation procedures for converting MIBs from ISO/CCITT GDMO template format into Internet MIB macro format. Chang Expires November 29, 1993 Page 2 Draft ISO/CCITT to Internet Management Proxy 5/26/93 The IIMC approach is to specify direct translation procedures which yield a pair of functionally-equivalent MIBs, as shown in the following figure. +----------------+ +--------------------+ +----------------+ | Internet MIB | | MIB Translation | | GDMO MIB | | | | Procedures | | | | Format = | | Specified By | | Format = | | [RFC1212] & |---->| [IIMCIMIBTRANS] or |---->| [ISO10165-1] & | | [RFC1442] |<----| [IIMCOMIBTRANS] |<----| [ISO10165-4] | +----------------+ +--------------------+ +----------------+ MIBs translated by these procedures may be used to take advantage of existing MIB definitions when business needs require deployment in a different management environment. Translated MIBs may also be used to provide uniformity when multiple management environments are supported by a single system (e.g., dual stack managers). Finally, IIMC MIB translation procedures may be used to support service emulation by a proxy. 1.4 Native Management Model The basic model for ISO/CCITT and Internet management is illustrated in the following diagram. Manager Agent +-----------------------+ +----------------------+ |+---------------------+| |+-------------------+ | || Management || || Managed | | || Applications || || Resources | | |+---------------------+| |+-------------------+ | | | | | | | | | | | | | |+-----------+---------+| |+----------+---------+| || Manager | MIB || || Agent | MIB || |+-----------+---------+| |+----------+---------+| | | | | | | | | Management | | | Management | | | Services | | | Services | +-----------------------+ +----------------------+ | Management Protocol | | Management Protocol | +-----------------------+ +----------------------+ ^ ^ | | +------------------------------------+ Protocol Messages Within IIMC documents, this model is referred to as the "native" management model. MIBs translated using IIMC procedures can be used by "native" agent implementations. For example, an ISO/CCITT agent can make visible TCP/IP managed resources using the translated GDMO version of the Internet Chang Expires November 29, 1993 Page 3 Draft ISO/CCITT to Internet Management Proxy 5/26/93 MIB-II [RFC1213] specified by [IIMCMIB-II]. Dual-stack managers or agents may also be implemented which support both the original MIB and the translated MIB generated using IIMC- specified procedures. 1.5 Proxy Management Model The basic model for ISO/CCITT to Internet proxy management is illustrated in the following diagram. This proxy is specified by [IIMCPROXY]. A similar approach could also be taken to specify an Internet to ISO/CCITT proxy, although no such IIMC document is currently specified. Manager Proxy Agent +-----------------------+ +---------------------+ +------------------ |+---------------------+| |+------+ +----------+| |+----------------- || Management || || GDMO | | Internet || || Managed || Applications || || MIB | | MIB || || Resources |+---------------------+| |+------+ +----------+| |+----------------- | | | |+-------------------+| | | | | | || Service || | | | | | || Emulation || | | | | | ||(scoping) || | | | | | || (filtering) || | | | | || (operations)|| | | |+-----------+---------+| |+-------------------+| |+----------+------ || ISO/CCITT | GDMO || || Protocols Mapping || || Internet | Inter || Manager | MIB || || CMIS |...| SNMP || || Agent | MIB |+-----------+---------+| |+-------------------+| |+----------+------ | | | | |CMIS | | | | | | CMIS Services | | |Services | | | | SNMP "Servic | | | | | | | | | | | | | | SNMP| | | | | | | | | "Services"| | | | +-----------------------+ +---------------------+ +------------------ | CMIP | | CMIP | SNMP | | SNMP +-----------------------+ +---------------------+ +------------------ ^ ^ ^ ^ | | | | +---------------------+ +-------------------+ CMIP Messages SNMP Messages This ISO/CCITT to Internet proxy provides emulation of CMIS services by mapping to the corresponding SNMP message(s) necessary to carry out the service request. The service emulation allows management of Internet objects by an ISO/CCITT manager. The left hand side of the proxy behaves like an ISO/CCITT agent, communicating with the ISO/CCITT manager using CMIP protocols. The right hand side of the proxy behaves like an Internet manager, communicating with the Internet agent using SNMP protocols. The proxy relies on the existence of a pair of directly- related MIB definitions, where the Internet MIB has been Chang Expires November 29, 1993 Page 4 Draft ISO/CCITT to Internet Management Proxy 5/26/93 translated into ISO/CCITT GDMO using the procedures specified in [IIMCIMIBTRANS]. The proxy uses these MIB definitions and rules to provide run-time translation of management information carried in service requests and responses. The proxy is designed with a specified interface between the proxy and the underlying protocol stacks, and so deals primarily in terms of CMIS services and SNMP "services". The proxy emulates services such as CMIS scoping and filtering, processing of CMIS operations, and forwarding/logging of CMIS notifications by performing a mapping process which must be tailored for each protocol (for example, SNMPv1 and SNMPv2 are variants of the same protocol mapping process). 1.6 Scope of this Document The intent of this document (IIMCPROXY) is to facilitate the use of ISO/CCITT CMIP-based managers to perform integrated management of networks via proxy management of networks that are accessed using Internet SNMP-based agents. There are two major differences between CMISE and SNMP services: the structure of management information, and the management operations supported by the underlying protocols. The ISO/Internet Proxy architecture as shown in section 1.2 provides CMISE service emulation. In another words, the ISO/Internet Proxy acts as a CMIP-based agent with respect to the manager, allowing management of Internet objects by the ISO/CCITT manager. CMIS requests are processed by the ISO/Internet proxy and CMIS responses are returned by the ISO/Internet proxy. SNMP traps and Inform requests are converted to CMIS notifications by the ISO/Internet proxy. The implementation of the proxy requires that the Internet MIBs be mapped to ISO/CCITT GDMO definitions. 1.6.1 Approaches to Service Emulation As described by [NMFTR107], there are different approaches for mapping Internet MIBs and ISO/CCITT MIBs. - The "direct translation" approach maps each Internet object to a newly defined ISO/CCITT GDMO object that contains: 1) the same information as contained in the Internet object; and 2) the attributes that are inherited from the ISO/CCITT Top object class. - The "abstract translation" approach maps Internet objects to different ISO/CCITT GDMO objects. For example, the MIB-II system object is similar to, and could be represented by, the ISO/CCITT system object. The abstract translation approach can also be used to map several Internet objects to a single ISO/CCITT GDMO object which provides only a summary view of the original Internet objects. Chang Expires November 29, 1993 Page 5 Draft ISO/CCITT to Internet Management Proxy 5/26/93 Either or both approaches could be used by an ISO/CCITT manager to manage Internet agents. This document uses the "direct translation" approach. To perform the CMISE service emulation, the ISO/Internet proxy can use either of the approaches described by [NMFTR107] to retrieve or modify Internet MIB information. - In the "stateless" approach, the proxy does not maintain the Internet agent's MIB data. Instead, for each received CMIS request, the ISO/Internet proxy generates one or more SNMP requests to the Internet agent in order to achieve the same intent of the CMIS request. - The "stateful" approach requires the proxy to replicate an Internet agent's MIB locally, and to send periodic (unsolicited) requests to Internet agents to keep the replicated MIB current. The ISO/Internet proxy then tries to fulfill each incoming CMIS request by using locally- replicated MIB data, instead of sending SNMP requests to the Internet agent. The "stateful" approach will usually provide better response time, but has the drawback that the data retrieved might not be current. In this approach, the poll frequency used to update the locally-replicated MIB has a significant effect on the accuracy of the response. This document uses the "stateless" approach in which the proxy responds to incoming CMIS requests by generating appropriate SNMP requests. Furthermore, SNMP traps and inform requests are converted to CMIS notifications. If necessary, the static Internet MIB data retrieved by the ISO/Internet proxy could be cached by the proxy in order to improve the response time of an operation. This document makes no assumption that the proxy caches static information, and so takes no advantage of information which might be cached. 1.6.2 Proxy Inputs and Outputs This document describes a proxy which emulates CMIS services through generation of appropriate SNMP protocols. The proxy is based on certain inputs and outputs, as shown below in Tables 1 and 2. CMIS services [ISO9595] are supported by CMIP version 2 protocol [ISO9596-1]. SNMP protocols are as defined for SNMPv1 [RFC1157] and SNMPv2 [RFC1448]. The emulation is slightly different, depending upon whether SNMPv1 or SNMPv2 protocols are being used. Chang Expires November 29, 1993 Page 6 Draft ISO/CCITT to Internet Management Proxy 5/26/93 +------------------------------+----------------------+ | Service | Source | +------------------------------+----------------------+ | ACSE Associate Indication | CMIP Stack | | ACSE Release Indication | CMIP Stack | | ACSE Abort Indication | CMIP Stack | | CMIS Get Indication | CMIP Stack | | CMIS Cancel Get Indication | CMIP Stack | | CMIS Set Indication | CMIP Stack | | CMIS Create Indication | CMIP Stack | | CMIS Delete Indication | CMIP Stack | | CMIS Action Indication | CMIP Stack | | CMIS Event Report Confirm | CMIP Stack | | SNMPv1 Get Response | SNMPv1 Stack | | SNMPv1 Trap | SNMPv1 Stack | | SNMPv1 Error | SNMPv1 Stack | | SNMPv2 Trap | SNMPv2 Stack | | SNMPv2 Get Response | SNMPv2 Stack | | SNMPv2 Get Bulk Response | SNMPv2 Stack | | SNMPv2 Inform Request | SNMPv2 Stack | | SNMPv2 Error | SNMPv2 Stack | +------------------------------+----------------------+ Table 1 - Proxy Inputs +------------------------------+----------------------+ |Service | Target | +------------------------------+----------------------+ | ACSE Associate Response | CMIP Stack | | ACSE Release Response | CMIP Stack | | ACSE Abort Request | CMIP Stack | | CMIS Get Response | CMIP Stack | | CMIS Cancel Get Response | CMIP Stack | | CMIS Set Response | CMIP Stack | | CMIS Create Response | CMIP Stack | | CMIS Delete Response | CMIP Stack | | CMIS Action Response | CMIP Stack | | CMIS Event Report Indication | CMIP Stack | | SNMPv1 Get Request | SNMPv1 Stack | | SNMPv1 Set Request | SNMPv1 Stack | | SNMPv1 Get Next Request | SNMPv1 Stack | | SNMPv2 Get Request | SNMPv2 Stack | | SNMPv2 Set Request | SNMPv2 Stack | | SNMPv2 Get Next Request | SNMPv2 Stack | | SNMPv2 Get Bulk Request | SNMPv2 Stack | +------------------------------+----------------------+ Table 2 - Proxy Outputs This document assumes that CMIP PDUs and SNMP PDUs received by the ISO/Internet proxy are always properly encoded (i.e., the underlying protocol stacks ensure the correctness of the service indications and confirmations that are passed up to the ISO/Internet proxy). Chang Expires November 29, 1993 Page 7 Draft ISO/CCITT to Internet Management Proxy 5/26/93 The security architecture, services, protocols, and mechanisms for the ISO/Internet proxy shall be as defined in [IIMCSEC]. 1.7 Terms and Conventions This document assumes that the reader is familiar with ISO/CCITT management and Internet management, and the terminology of each. The term "SNMP" is used throughout this document to indicate either SNMPv1 or SNMPv2, unless a distinction needs to be made. Other terms and conventions used throughout this document include the following. 1. ISO/CCITT manager: An application entity that implements [ISO9596-1] and acting in the manager role. 2. Internet agent: An application entity that supports the agent role of one or more of the SNMP protocols, such as [RFC1157] or [RFC1448]. 3. ISO/Internet Proxy: An application entity that is responsible for emulating CMIS requests by a) generating SNMP requests, b) using SNMP responses to generate CMIS responses, and c) mapping SNMP Traps and InformRequests to CMIS notifications, all between a given (ISO/CCITT manager, Internet agent) pair. A proxy may concurrently support more than one (ISO/CCITT manager and Internet agent) pair. 4. Known Internet agents: A set of one or more Internet agents that an ISO/Internet proxy has knowledge of. Each known Internet agent is represented by an instance of the proxy object. This document defines the cmipsnmpProxyAgent object class. 5. Known SNMP Parties: A set of one or more SNMP parties that an ISO/Internet proxy has knowledge of. Each known SNMP party is represented by an instance of the partyTable object. The partyTable object class is defined in [IIMCSEC]. 6. Pseudo Object: A GDMO object class that does not contain any attributes which may be retrieved from an Internet agent (for example, a GDMO object class that represents a group in the Internet MIB-II, or any GDMO object classes representing Internet MIB tables). 7. Local object (instance): An object instance that is implemented by the proxy itself (for example, the cmipsnmpProxy and cmipsnmpProxyAgent classes defined in section 7). Chang Expires November 29, 1993 Page 8 Draft ISO/CCITT to Internet Management Proxy 5/26/93 8. Remote object (instance): An object instance that physically resides within an Internet agent is considered a "remote object" (for example, Internet MIB-II objects like system, tcp, and udp). 9. Multiple Instance Object: An object class that may have more than one object instance. For example, Internet MIB table entries. 10. Delete Information: The object identifier of the attribute and its attribute value used to indicate that a particular row of a table is deleted. 11. Proxy System Object: The [ISO10165-2] DMI system managed object instance that represents the proxy itself. 12. Remote System Object: The [ISO10165-2] DMI system managed object instance that represents the remote proxied device on which the Internet agent resides. Abbreviations CMIP: Common Management Information Protocol CMIS: Common Management Information Service CMISE: Common Management Information Service Element DN: Distinguished Name MIB: Management Information Base MOC: Managed Object Class (CMIP) MOI: Managed Object Instance (CMIP) MIT: Management Information Tree (naming tree) OID: ASN.1 Object Identifier PDU: Protocol Data Unit RDN: Relative Distinguished Name SNMP: Simple Network Management Information Protocol SNMPv1: Simple Network Management Information Protocol version 1 [RFC1157] SNMPv2: Simple Network Management Information Protocol version 2 [RFC1448] Chang Expires November 29, 1993 Page 9 Draft ISO/CCITT to Internet Management Proxy 5/26/93 2 ISO/Internet Proxy Configuration In order for the ISO/Internet proxy to interwork with the known Internet agents, the proxy needs to know initialization information such as the transport address, network address, protocol version, and security policy for each of the known Internet agents. Such configuration may be done through an off-line process, or through an on-line management exchange not specified by this document. 2.1 ISO/Internet Proxy Containment Tree The proxy shall support a forest of object instance trees, each rooted at the ISO/CCITT system managed object defined by [ISO10165-2], with one system object instance for each supported Internet agent, and one system object instance for the proxy itself. Each ISO/CCITT system object is distinguished by the value of its systemId or systemTitle attribute, containing the name associated with the Internet agent or proxy application. This ISO/CCITT to Internet Proxy containment tree is shown below. "Containment Object" | +----------------+-+--------------------------+ | | ... | Proxy System Remote System 1 Remote System N | | | +---+-+-----+ +---+-+---+ +--+--+----+ | | ... | | | ... | | | .... | Objects in Objects in Objects in Proxy System Remote System 1 Remote System N The "Proxy System" is the [10165-2] "system" managed object instance that represents the proxy itself. The Proxy System contains all objects representing resources within the proxy itself, including the cmipsnmpProxy and cmipsnmpProxyAgent managed objects. The "Remote System" is the [10165-2] "system" managed object instance that represents the remote proxied device on which the Internet agent resides. The Remote System contains all objects that are implemented by the remote Internet agent. These would include [IIMCMIB-II] "internetSystem", and any other object supported by the Internet agent. All objects in the above containment tree can be accessed by scoping from the "Containment Object". This may be an instance of any managed object class. One possible "Containment Object" is the so-called global root (i.e., "CCITT Rec. X.660 | ISO/IEC 9834-1 : 1992":root). In this case, scoped requests Chang Expires November 29, 1993 Page 10 Draft ISO/CCITT to Internet Management Proxy 5/26/93 including all Remote Systems can be achieved by using a management operation with the base object class equal to "actualClass" and the base object instance name equal to "{}". The proxy may support other alternative "Containment Objects"; this choice is left to the implementor. 2.2 System Objects The "Proxy System" object particular to the proxy shall be created automatically by the proxy during its local initialization. The "Remote System" object particular to an Internet agent system shall be automatically created/deleted by the proxy when an associated cmipsnmpProxyAgent object instance in the Proxy MIB is created/deleted. The Distinguished Name of this system object shall have the same value as the cmipsnmpProxyId attribute in the associated cmipsnmpProxyAgent object instance. Creation/deletion of the system object via management operation is not allowed. The operationalState attribute of the "Remote System" object indicates the perceived state of the Internet agent. It is the same as the operationalState attribute defined in [ISO10165-2]. That is: - The "enabled" state means that the Internet agent is operational, as perceived by the proxy, i.e., it can be reached. - The "disabled" state means that the Internet agent is not operational, as perceived by the proxy, i.e., it cannot be reached. The validity of the operationalState attribute is dependent on the mechanisms used by the proxy to determine reachability, and the frequency with which it is invoked. For connectionless environments (e.g., UDP), polling will have to be performed by the proxy. For connection oriented environments (e.g., TCP), loss of connectivity as indicated by lack of "keep alive" messages can be used to provide this information. Editor's Note: [The intended semantic of these state attributes requires further consideration.] 2.3 Translated MIB Schema Information To perform CMISE service emulation, the ISO/Internet proxy requires the Internet MIB's schema information, described in ISO/CCITT GDMO templates. These templates shall be derived from the original Internet MIB according to the procedures defined by [IIMCIMIBTRANS]. Chang Expires November 29, 1993 Page 11 Draft ISO/CCITT to Internet Management Proxy 5/26/93 The proxy run-time translation of parameters and protocol translation procedures defined in this document depend on the MIB translation, naming and registration procedures defined in [IIMCIMIBTRANS]. The translation and registration procedures defined in that document are structured such that the maximum amount of information is preserved to facilitate the translation process. An example containment tree for an agent supporting the ISO/CCITT GDMO Internet MIB-II [IIMCMIB-II] (derived from the Internet MIB-II [RFC1213]) is illustrated below. A proxy would have multiple instances of such a tree for each Internet agent supported. (The actual structure of the each containment tree depends upon the MIB(s) supported by the proxy.) "Rec. X.721 | ISO/IEC 10165-2 : 1992" : system | |-- internetSystem | |-- at --- atTable --- atEntry | |-- egp --- egpNeighTable --- egpNeighEntry | |-- icmp | |-- interfaces --- ifTable --- ifEntry | |-- ip --- ipRouteTable --- ipRouteEntry | | | |---- ipAddrTable --- ipAddrEntry | | | |---- ipNetToMediaTable -- ipNetToMediaEntry | | | |---- ipForwardTable --- ipForwardEntry | |-- snmp | |-- tcp --- tcpConnTable --- tcpConnEntry | |-- udp --- udpTable --- udpEntry As specified in [IIMCIMIBTRANS], name bindings for ISO/CCITT GDMO object classes derived from Internet MIB table and entry types can be automatically inferred from the Internet registration hierarchy. Thus, object classes derived from Internet conceptual table objects are bound to the object class derived from the group with which the table is associated. Object classes derived from Internet conceptual table entries are bound to the table object classes with which the tables entries are associated. Also, object classes derived from Internet groups are bound to the ISO/CCITT system object class. Chang Expires November 29, 1993 Page 12 Draft ISO/CCITT to Internet Management Proxy 5/26/93 2.4 IIMC Party MIB Objects Information regarding security policy when accessing agents is contained in Party MIB objects. Binding the Party MIB objects as subordinates of the system object which represents an individual Internet agent allows security policy to be applied on a per Internet agent basis. The Party MIB information can be used by the proxy in a manager role when security services enforcing security policy are implemented in the Internet agent. The services enforced may be authentication, access control, confidentiality and integrity as defined in [RFC1446]. In those situations where the agents may not implement the access control security service on requests from the ISO/CCITT manager (e.g., SNMPv1 agents), the proxy may enforce those services on behalf of the Internet agent. The policy regarding where access control is to be applied is controlled by variables in the cmipsnmpProxy and cmipsnmpProxyAgent managed objects defined in section 7. The policy regarding security services other than access control, must always be enforced by the Internet agent. A containment tree diagram for IIMC Party MIB managed object classes is illustrated below. The IIMC Party MIB is subordinate to the ISO/CCITT system managed object that represents the Internet agent. "Rec. X.721 | ISO/IEC 10165-2 : 1992" : system | |-- partyTable --- partyEntry | |-- contextTable --- contextEntry | |-- aclTable --- aclEntry | |-- viewTable --- viewEntry 2.5 IIMC Proxy MIB Objects The IIMC Proxy MIB defines a set of objects for specifying the information that is needed for both community-based and party- based SNMP management on a per Internet agent basis. The Proxy MIB consists of a cmipsnmpProxy managed object which contains cmipsnmpProxyAgent object instances, one for each agent being managed by the proxy. The cmipsnmpProxy object class is an immediate subordinate of the "Proxy System" object class. The cmipsnmpProxy object also contains an snmpSecurityParameter object instance which contains default security information. Chang Expires November 29, 1993 Page 13 Draft ISO/CCITT to Internet Management Proxy 5/26/93 Each cmipsnmpProxyAgent object has information which identifies an Internet agent and how the agent may be reached. Its naming attribute, which contains the administratively- assigned name of the managed device where the Internet agent is located, is used in the naming tree to identify the SNMP managed device. Creation of a cmipsnmpProxyAgent object instance to represent an Internet agent shall result in the instantiation of a corresponding "Remote System" object representing the Internet agent. The naming attribute value of the "Remote System" shall be the same as the name of the corresponding cmipsnmpProxyAgent object instance. It is recommended that a "OP1 Library Vol. 4":capabilityObject be created for the proxy also. The cmipsnmpProxyAgent object may be created by management operation, or automatically. For example, the proxy may support discovery of Internet agents, whereby the discovered Internet agents, associated system object, and capability object shall be created automatically by the proxy itself. This document refers to instances of IIMC Proxy MIB object classes as "local objects" or as "local object instances". A containment tree diagram for ISO/CCITT proxy MIB managed object classes is illustrated below. "Rec. X.721 | ISO/IEC 10165-2 : 1992" : system | +-- cmipsnmpProxy | +--cmipsnmpProxyAgent | +--snmpSecurityParameter IIMC Proxy MIB GDMO definitions are described in section 7. 2.6 OMNIPoint 1 Capability Object If used, the "OP1 Library Vol.4":capability object particular to an Internet agent system shall be automatically created and deleted by the proxy when the associated cmipsnmpProxyAgent object in the Proxy MIB is created and deleted. The following text describes one possible implementation of gathering information defined in the Capability object's supportedObjectClassList. When the cmipsnmpProxyAgent is created, or when the supportedObjectClassList attribute changes, the proxy shall find out all the object classes defined in all the GDMO documents described in the supportedMIBs attribute. The proxy then forms an SNMP Get Next Request with all the object classes (translated to the OID used by the Internet agent) in a variable binding list to Chang Expires November 29, 1993 Page 14 Draft ISO/CCITT to Internet Management Proxy 5/26/93 find out whether a particular object class is supported by the Internet agent. The proxy then fills the supportedNameBindingList by finding out all the name bindings used by the object classes in the supportedObjectClassList. 2.7 MIB Usage The information described in sections 2.1 through 2.6 is maintained by the proxy and used to perform run-time translation between corresponding CMIS and SNMP parameters. The following definitions are extracted from [IIMCIMIBTRANS] clause 2.3.1, where (c) and (a) refer to class and attribute, respectively. From [IIMCIMIBTRANS] clause 2.1: {classOID} ::= {iimcAutoTrans <internetEntityId>(c)} and {attributeOID} ::= {iimcAutoTrans <internetEntityId>(a)} From [IIMCIMIBTRANS] clause 2.2, the ISO/CCITT naming attribute value contains the OID formed as: (naming attribute) ::= {iimcAutoTrans <internetEntityId>(c) <internet instanceId>} where the "()" indicates "contents of". The <internet instanceId> (the OID created uniquely for each Internet object instance) is "0" for object classes that may only have a single instance. The <internet instanceId> for object classes that may have multiple instances is an OID fragment derived from the values of the internet objects identified in the INDEX (or AUGMENTS) clause of the Internet Macro from which the object class is derived, as defined in [RFC1155] or [RFC1442]. The Internet uses the following convention to uniquely identify an Internet object instance: {internet object name}::= {<internetEntityId>(a) <internet instanceId>} Refer to [IIMCIMIBTRANS] for additional detail. 2.8 Retained Information Chang Expires November 29, 1993 Page 15 Draft ISO/CCITT to Internet Management Proxy 5/26/93 The proxy must retain information obtained from the ISO/CCITT manager during association establishment, and for individual CMIS requests on the association. For each outstanding CMIS request, the proxy needs to maintain the ISO/CCITT invoke id, object class and object instance. When SNMP responses are received, the proxy shall use the retained information to form the associated parameters in CMIS responses. For scoped CMIS requests, the proxy shall maintain some state information to keep track of the portion of the Internet MIB that is being traversed. 3 Elements of CMIS Service Emulation The following sections describe the conceptual process for performing CMIS service emulation. In an actual implementation, it should be possible to combine some of the processing. It is highly recommended that the implementors of the ISO/Internet proxy combine the processes where possible to optimize the implementation. 3.1 Association Service The proxy should provide the association service as defined in section 8.1 of [ISO9596-1]. This service includes association establishment and association release. In ISO/CCITT systems management, management entities may exchange initialization information during the association establishment phase. Such information is used only by the proxy for its own configuration and is not conveyed to the communicating Internet agents. This document does not define any application context; however, a proxy may be required to support the following application contexts as defined in the ISO standards and CCITT recommendations: ISO Systems Management application context; or CCITT TMN application context one. CMIP and SMASE functional units may be negotiated between the ISO/CCITT manager and the ISO/Internet proxy. Once a set of functional units is agreed, the proxy will ensure only the agreed services are accepted over the association. The CMIP protocol used between the ISO/CCITT manager and the ISO/Internet proxy is a connection-oriented protocol which requires an association be maintained throughout the management exchange(s). The protocol between the proxy and the Chang Expires November 29, 1993 Page 16 Draft ISO/CCITT to Internet Management Proxy 5/26/93 Internet agent, however, may be a connection-less protocol which does not require the existence of an association. Upon receiving an association request from the ISO/CCITT manager, the proxy needs to determine whether connectivity to the agent is possible so that it may accept or reject the association request accordingly. The mechanism used by a proxy to detect the "reachability" of an Internet agent is implementation- dependent, and is not within the scope of the document. For example, if the reliability of the association is not essential to its management applications, a proxy may assume its Internet agents are always reachable, and may accept association requests on that basis. In this approach, the proxy would terminate the association only when it detects the Internet agent is not reachable. 3.2 Object Selection - Scoping and Filtering Managed object selection is used to identify a set of managed object instances in the management information tree (MIT) to which a CMIS request applies. Managed object selection is performed in two phases: scoping; and then, filtering. Scoping is used to select candidate object instances in the MIT to which operations may apply. A filter is then applied to attributes of the previously scoped object instances in order to identify the subset of object instances on which the CMIS operation is to be performed. If no filter is specified, the CMIS request will be performed for all object instances identified by the scope parameter. If no scope parameter is specified, the default is the base managed object instance only. There are different ways of performing the scoping operation, depending on the implementation. This document specifies one possible way of providing the managed object selection service. The proxy has no direct knowledge of current object instances that exist in the Internet agent. Therefore, it must first determine the existence of an object before it knows whether it is within the scope. Obviously, all objects in the scope must be instances of object classes that are within the scope. Thus, the proxy should first determine the set of object classes within the scope, and then discover what instances of those object classes actually exist in the Internet agent. This set of object classes that are within the scope are called the "object class group" (OCG). The following pseudo code algorithm specifies a generic method of determining the members of an "object class group". Chang Expires November 29, 1993 Page 17 Draft ISO/CCITT to Internet Management Proxy 5/26/93 Define the set of object classes at the current level in the naming tree that are being processed as the "class level group" (CLG). Define the set of object classes at the next level in the naming tree that are to being processed after the CLG as the "next level group" (NLG). Define the managed object class named by the incoming request as the "base managed object" (BMO). Minimum Level and Maximum Level are derived from the CMIS scope parameter. CLG = {BMO}; OCG = {}; /* empty set */ currentScope = 0; WHILE ( currentScope <= Maximum Level ) NLG = {children of objects in CLG}; IF (currentScope > Minimum Level) THEN OCG = {union of OCG and CLG}; CLG = NLG; currentScope = currentScope + 1; ENDWHILE; The determination of the set NLG as {children of objects in CLG} may be done using implementation-dependent internal data structures of the proxy. An alternative method to determine NLG is to use the name binding templates directly. The following algorithm could then be used to determine the NLG. WHILE (CLG not equal to {}) Remove an object from CLG; FOR (all name bindings in this proxy's associated Capability object) IF object == SUPERIOR THEN NLG = {union of the SUBORDINATE object and NLG}; ENDFOR; ENDWHILE; 3.3 Management Operation Services If the specified instances (i.e., those selected by scoping process) are "local objects", the proxy performs the services using local means. If the specified instances are "remote objects", then the following steps apply. Any objects that physically reside in the Internet agents are considered "remote objects". For Chang Expires November 29, 1993 Page 18 Draft ISO/CCITT to Internet Management Proxy 5/26/93 example, Internet MIB II objects like system, tcp, and udp are considered "remote objects". 1) Determine if the attributes specified by the filter expression (if any) belong to the object class. If not, then remove the object class from the object class group. 2) If the object is a pseudo object (table object), then there is only one possible instance and the values of the attributes are known locally to the proxy. The pseudo object exists if and only if there exists a non-pseudo subordinate object (table entries). The proxy shall attempt to determine if there exists a non-pseudo subordinate object by issuing an SNMP GetNext Request using as an argument the Internet object name for the pseudo object, <internetEntityId>(c). If the SNMP response contains an Internet object that translates to an attribute of a child of the pseudo object, then the pseudo object exists. If the pseudo object does not exist, then remove it from the object class group. 3) If the object is not a pseudo object, then determine if an instance of the object exists by attempting to retrieve, for the first instance, all of the attributes specified in the CMIS filter and the attributeId list or attribute list. i) For single instance objects, use an SNMP Get Request or GetNext Request, with the parameters translated according to section 4. ii) For multiple instance objects, use an SNMP GetNext Request, with the parameters translated as shown in section 4. This will result in the retrieval of the first instance of the translated Internet objects (i.e., a table entry). If the resulting table entry has been deleted, or is otherwise unavailable for retrieval, then go to step 5. 4) Apply the filter to the attributes of the object instance identified in steps 2 and 3. i) If the filter evaluates to FALSE, then perform no further processing on the object. However, for multiple instance objects, save the results of step 3 part (ii). ii) If the filter evaluates to TRUE, then attempt to perform the operation on the object, as follows. - If the CMIS operation was M-GET, then the M-GET has been completed from the Internet agent. Formulate the appropriate CMIS M-GET response and send it to the manager. Chang Expires November 29, 1993 Page 19 Draft ISO/CCITT to Internet Management Proxy 5/26/93 - If the CMIS operation was M-SET, then perform the corresponding SNMP Set Request on the Internet objects. When the SNMP Response returns, formulate the appropriate CMIS M-SET response and send it to the manager. - If the CMIS operation was M-CREATE, then perform the create on the Internet objects (conceptual row elements) using the algorithm appropriate to the object. When the create process is finished, formulate the appropriate CMIS M-CREATE response and send it to the manager. - If the CMIS operation was M-DELETE, then perform the delete on the Internet objects. When the SNMP Response returns, formulate the appropriate CMIS M-DELETE response and send it to the manager. 5) For multiple instance objects, use an SNMP GetNext Request, with the parameters translated according to section 4, and with the <internet instanceId> set to the values retrieved for the previous instances for all Internet object names. This will result in the retrieval of the next instance of the translated Internet objects. If the Internet object instances are not of the same type as those requested, then all instances of the multiple instance object class have been processed; go to step 6. If the Internet object instances are of the same type as those requested then retain the results of the GetNext Request for the next iteration and repeat steps 4 and 5. In order to reduce the amount of traffic generated by multiple Get-Next requests, the proxy could use the SNMPv2 Get-Bulk request with the non-repeaters parameter set to zero and the max-repetitions set to some arbitrary value (either by guessing or based on previous knowledge). Setting non-repeaters to zero makes the Get-Bulk operation behave like Get-Next. 6) Attempt to select another object class from the object class group. If one exists then go to step 1; otherwise, return an appropriate final CMIP PDU (e.g., empty M-GET or M-SET response) and quit processing the request. 3.4 Synchronization If the ISO/Internet proxy receives a CMIS "atomic" request, but cannot perform the operation atomically, the "synchronization not supported" CMIS error response should be returned to the ISO/CCITT manager. Chang Expires November 29, 1993 Page 20 Draft ISO/CCITT to Internet Management Proxy 5/26/93 If SNMPv1 is used, the types of atomic requests that the ISO/Internet proxy can perform are as follows. 1) If all the instances selected by a scoped CMIS request are "local object instances", then the ISO/Internet proxy can perform the CMIS request locally (and atomically); and 2) If the CMIS request can be performed by the ISO/Internet proxy using a single SNMP request, then the operation can also be performed atomically. In SNMPv1, either a Get or Set operation would fail if the operation on any selected variable(s) failed. This remains true for SNMPv2 Set operations, but not for SNMPv2 Get operations. Using SNMPv2, if you request 4 variables in a Get request, and there is an error in one of the variables, you get a response with 3 valid values and one error. The proxy shall fail a CMIS "atomic" request if the corresponding SNMPv2 Get operation is only partially successful. For a "best effort" request, the ISO/Internet proxy should try to perform the request on all the instances specified by the request. Since the SNMP protocol supports only "atomic" operations, an operation (especially an SNMP Set Request operation) on multiple variables may be rejected if the operation on any one of the selected variables failed. Upon receiving such an error, the proxy should retry the request by sending multiple requests with each request containing only a single variable. In the time window in which these SNMP requests are being processed, another SNMP Set Request could be issued which could modify the value of a selected variable. For this reason, the complete integrity of a CMIS scoped request cannot be guaranteed. A proxy which complies with this document is not required to detect or avoid this situation, and will not usually report any error if this situation occurs. 3.5 M-GET Service The following sub-sections describe how the M-GET service may be emulated. Upon receiving a CMIS M-GET request, the proxy first verifies the existence of the based managed object. The procedures for verifying the existence of a managed object is described in section 4.1. 3.5.1 Form The Request If the CMIS request's attributeIdList parameter is empty (selects all attributes), the proxy shall query the schema Chang Expires November 29, 1993 Page 21 Draft ISO/CCITT to Internet Management Proxy 5/26/93 information to find out what attributes are specified for the requested object class. If the CMIS request's attribute specifies a non-null attributeIdList, the proxy shall verify that the identified attribute(s) are specified for the object class. If the identified attribute is not specified in the object class, the proxy shall return a noSuchAttribute CMIS error without sending SNMP requests to the Internet agent. For all attributes that are specified in the object, an SNMP Get or SNMP GetNext Request shall be formed, based on the mapping specified in section 4. Use of SNMP Get or GetNext is an implementation issue; however, SNMP GetNext is recommended for performance reasons. Since some non-conforming agents may not implement all the object types in an object group, SNMPv1 Get would return a noSuchName error in this case, and the proxy will need to remove the non-implemented variable binding and resend the SNMP Request. If SNMP GetNext is used instead, the proxy would either discard the non-implemented attribute or translate the SNMP Response to appropriate CMIS getListError. 3.5.2 Form The Response(s) The proxy shall form the CMIS response according to the mappings specified in section 4. If the CMIS request's attributeIdList is null (selects all attributes), the proxy shall never return the CMIS getListError. If the Internet agent does not implement all the variables in an object (which violates conformance to the SNMP specification), the proxy shall form the CMIS M-GET response with all the attributes implemented by that Internet agent. If the CMIS request's attributeIdList selects all attributes, the proxy shall supply in all the attributes that are inherited from the ISO/CCITT Top object in the CMIS response. 3.6 M-CANCEL-GET Service The M-CANCEL-GET operation shall be performed as described in [ISO9596-1]. The ISO/Internet proxy does not need to generate any SNMP Requests in order to emulate the CMIS M-CANCEL-GET request. However, upon receiving an M-CANCEL-GET request, the ISO/Internet proxy shall stop sending further CMIS M-GET responses to the ISO/CCITT manager for the canceled M-GET request. Furthermore, the proxy shall not initiate further SNMP Requests to the Internet agent for the canceled M-GET request. If the Internet agent continues to return SNMP Get responses corresponding to the canceled M-GET request, they shall be discarded by the proxy. Chang Expires November 29, 1993 Page 22 Draft ISO/CCITT to Internet Management Proxy 5/26/93 Depending on when an M-CANCEL-GET request is received, the proxy may send out different responses for the canceled M-GET request and for the M-CANCEL-GET request. If the Invoke Id of the M-GET request to be canceled is not recognized by the proxy, the proxy shall return a "no such invoke identifier" CMIS error to the ISO/CCITT manager. This can happen when the proxy has not received such an M-GET request, or when the proxy has completed the identified M-GET request. An M-GET operation is considered completed if the corresponding M-GET response has been sent. For the single object M-GET case, this means the sending of a single M-GET response. For the scoped multiple object case, this means the sending of the final empty M-GET response for the linked replies. If the identified M-GET request was received, but has not been completed, the proxy generates an "operation canceled error" to the ISO/CCITT manager as a response to the canceled M-GET request. In this case, the proxy will also acknowledge the successful completion of the M-CANCEL-GET request to the ISO/CCITT manager. 3.7 M-SET Service The following sections describe how M-SET service may be emulated. Upon receiving a CMIS M-SET request, the proxy verifies the existence of the based managed object, according to the procedures defined in section 4.1. 3.7.1 Perform The Set Operation For each selected ISO/CCITT object instance, the proxy would generate one or more SNMP Set Requests to modify the attributes identified by the CMIS modificationList parameter, according to the specified modify operator. Only the "replace" modify operator is supported by the ISO/Internet proxy. The modify operator is optional and if it is not specified in a CMIS request, the "replace" operator should be assumed. The CMIS "add value" and "remove value" modify operators are not supported by SNMP protocol, and are not supported by the ISO/Internet proxy. Since SNMP uses default values only for initialization (i.e. at creation time), the "set to default" modify operator is not supported by the ISO/Internet proxy either. If the modify operator value included in an M-SET request is not supported, "invalid operator" should be reported in the CMIS setListError response. 3.7.2 Form The Response(s) Chang Expires November 29, 1993 Page 23 Draft ISO/CCITT to Internet Management Proxy 5/26/93 If the M-SET request is a "confirmed" request, the proxy shall construct an M-SET response. The CMIS M-SET response should contain the attribute values list or the appropriate setListError. Once the CMIS M-SET response has been constructed, it is passed to the CMIP service provider, which send the corresponding CMIP PDU to the ISO/CCITT manager. If the CMIS M-SET request is a scoped request, attribute values of each ISO/CCITT object are reported as a linked reply. 3.8 M-ACTION Service Since Internet MIBs do not have any actions defined, the translation of CMIS M-ACTION to corresponding SNMP operations is not needed. Any CMIS M-ACTION request which is received pertaining to a translated Internet MIB object will be rejected by the proxy with an "noSuchAction" error response. However, CMIS M-ACTION may be used by the proxy for other purposes. 3.9 M-CREATE Service 3.9.1 Request Validation The ISO/Internet proxy is responsible for validating that incoming CMIS M-CREATE requests do not violate name binding and object class definitions. 3.9.2 Name Binding The ISO/Internet proxy must determine if an instance may be created according to the CREATE clause of the NAME BINDING template specified for the object class. If the instance cannot be created, the CMIS error response "classInstanceConflict" is returned. The ISO/Internet proxy must also determine from the NAME BINDING template if the instance specified in the request maybe created under the superior object instance identified in the M-CREATE request. If the NAME BINDING does not specify the identified containment relationship, an "invalidOperation" CMIS error response should be returned. 3.9.3 Check For Duplication The proxy must determine if the instance already exists. If it does, a "duplicate managed object instance" CMIS error response should be returned. 3.9.4 With Referenced Object Chang Expires November 29, 1993 Page 24 Draft ISO/CCITT to Internet Management Proxy 5/26/93 If a CMIS M-CREATE request includes a reference object, the ISO/Internet proxy should retrieve the referenced object instance from the Internet agent. The proxy uses an SNMP GetNext Request for retrieval, with the parameters translated according to section 4, and with the <internet instanceId> set to the translated <internet instanceId> of the reference object for all Internet object names. The proxy checks if the attribute used for SNMP row creation indicates that the row is not available for use (e.g., has been deleted or is in some other not ready condition). This attribute is the CREATEDELETEATT attribute indicated in the scannable portion of table entries translated according to [IIMCIMIBTRANS]. (Note that this attribute is always defined as GET only in the translated GDMO MIB.) If the reference object instance does not exist, the proxy must send a "No such reference object" CMIS error response to the ISO/CCITT manager. 3.9.5 With Automatic Instance Naming A CMIS M-CREATE request can use automatic instance naming to form a name for the object instance to be created. Automatic instance naming is used if: a) a CMIS M-CREATE request does not specify a distinguished name for the object instance to be created; and b) the request specifies an object class that has a name binding allowing automatic instance naming. It is the responsibility of the ISO/Internet proxy to select an instance name based on the behavior of the object class and name binding. In some cases, the relative distinguished name (RDN) is formed using attributes provided in the CMIS M-CREATE request. For example, the RDN for the Internet MIB-II "atEntry" could be formed from the "atNetIfIndex" attribute and the "atNetAddress" attribute. In other cases, the RDN can be assigned by the ISO/Internet proxy. If the superior object instance is not specified, the ISO/Internet proxy cannot create the object instance and a "processing failure" CMIS error should be returned. 3.9.6 Perform The Create Operation The CMIS M-CREATE is realized by setting the status column of the corresponding Internet MIB table entry to a valid value with all other columns of the table entry properly initialized. If the combination of the attributes specified in the CMIS M-CREATE request and the attributes obtained from the reference object do not provide a complete set of attribute values for all of the mandatory attributes for the entry specified by the object class being instantiated, then the Chang Expires November 29, 1993 Page 25 Draft ISO/CCITT to Internet Management Proxy 5/26/93 ISO/Internet proxy should still try to create the object with all the available attributes. If the actual creation process with the incomplete attribute list succeeds, the ISO/Internet proxy should retrieve all the attributes of the newly-created entry, including the attributes which have values supplied by the Internet agent with using default values. This complete list of attribute values is returned in the CMIS M-CREATE response. If the actual creation process with this partial attribute list fails, the ISO/Internet proxy sends a "missing attribute value" CMIS error back to the ISO/CCITT manager. 3.9.7 Form The Response The results from the Internet agent are used by the proxy to construct a CMIS M-CREATE response, which is then returned to the ISO/CCITT manager, using the mappings defined by section 4. 3.10 M-DELETE Service 3.10.1 Perform the Delete Operation For all the selected ISO/CCITT object instances, the following procedures should be taken. 3.10.2 Name Binding Determine from the NAME BINDING template if the instance specified in the request may be deleted. If the name binding does not allow the deletion of the identified object, a CMIS error response is returned. 3.10.3 Perform The Delete Operation If the object instance identified in the CMIS M-DELETE request exists, the delete operation is performed. In SNMPv1, object deletion is achievable only if there is a columnar object representing the status of each conceptual row. Deleting an object instance is realized by setting the status columnar object to an invalid value. The value representing "invalid" is implementation-specific. The proxy therefore needs to be aware of the "invalid" value and the status columnar object in order to perform the deletion. For SNMPv2, the object deletion can be achieved by sending an SNMP Set Request to the Internet agent to change the Row Status value to "destroy." 3.10.4 Form The Response(s) This process includes formatting the CMIP M-DELETE response with the appropriate attribute list or deleteListError Chang Expires November 29, 1993 Page 26 Draft ISO/CCITT to Internet Management Proxy 5/26/93 parameters. Once the CMIS M-DELETE response has been constructed, it is returned to the ISO/CCITT manager. 3.11 Management Notification Services Although SNMPv1 and SNMPv2 use different PDU structures to convey Traps, all SNMP Traps are mapped to the IIMC-defined internetAlarm notification and sent as CMIS M-EVENT-REPORTs. Since SNMP Traps are not confirmed, the translated CMIS M- EVENT-REPORTs are sent as "unconfirmed" event reports. If the SNMPv2 manager-to-manager communication is supported between an Internet manager and an ISO/CCITT manager, it is possible for the proxy to receive an InformRequest from the Internet system. Like Traps, InformRequests are also mapped to CMIS M-EVENT-REPORTs. Unlike Traps, the internetAlarm notifications resulting from InformRequests are sent as "confirmed" event reports. If the translation of Traps to notifications fails, no CMIS M- EVENT-REPORT will be generated and the SNMP Traps are simply discarded. The proxy shall expect a CMIS M-EVENT-REPORT response for all internetAlarm notifications sent in confirmed mode. The CMIS M-EVENT-REPORT response shall contain an empty event report argument. Upon receipt of the CMIS M-EVENT-REPORT response, the proxy shall return an SNMP Response PDU to the Internet agent that is in accordance with SNMPv2 protocol rules and contains an error code of "noError". If the translation of an SNMPv2 InformRequest to a CMIS M- EVENT-REPORT fails, the proxy shall send an SNMP Response to the originator of the SNMP InformRequest with the error code of "genErr". If the proxy cannot determine the Internet agent that initiated the SNMP Trap, then the CMIS M-EVENT-REPORT shall be sent as if it originated from the cmipsnmpProxy managed object class. This can occur when there are multiple agents associated with the same network address or when the proxy is unable to recognize the network address. Otherwise, the proxy should always be able to determine the originator from the network address in the Trap message and the event will be sent as if it originated from the MIB-II internetSystem under the remote system. Refer to section 6 for additional information regarding discrimination of notifications. Chang Expires November 29, 1993 Page 27 Draft ISO/CCITT to Internet Management Proxy 5/26/93 4 Common Procedures For CMISE Service Emulation The procedures described in this section are used during CMISE service emulation defined in section 3. These procedures are collected together here for ease of specification, and to facilitate common implementation. 4.1 Verifying Existence Of An Object Instance Since the proxy does not maintain a replicate copy of the MIB data maintained by the Internet agents, the existence of the a managed object, such as a based managed object specified in an incoming CMIS request, may need to be verified before further processing, such as scoping and filtering. If the base object specified in the request does not exist in the Internet agent, then the proxy must send a "NoSuchObjectInstance" CMIS error response back to the ISO/CCITT manager. If the base managed object is a pseudo object, the ISO/Internet proxy tries to determine if there exists a non- pseudo subordinate object. The base object exists if and only if there exists a non-pseudo subordinate object. 4.2 Translating Timestamps This document does not specify a standard translation for the timestamp value in CMIS responses. However, the following paragraphs describe two potential implementations for this translation: ISO/Internet proxy's local time, and Internet agent's local time with fixed unknown delta. 4.2.1 ISO/Internet Proxy's Local Time The timestamp value in the CMIS response can be set to the time provided by the ISO/Internet proxy's internal clock when the final SNMP Response is received to complete processing of a given CMIS request. 4.2.2 Internet Agent's Local Time The ISO/Internet proxy can query the Internet agent for "sysUpTime", in addition to the original SNMP variable binding list in the first SNMP Request. Using this method, this value is recorded as the "agent's initial sysUpTime" and the ISO/Internet proxy's local time is recorded as "initial contact time". Chang Expires November 29, 1993 Page 28 Draft ISO/CCITT to Internet Management Proxy 5/26/93 Each CMIS request is then translated to one or more SNMP Requests by the ISO/Internet proxy to fulfill the CMIS request. If the last SNMP Request for the same CMIS request is an SNMP Get Request, the "sysUpTime" is added into the SNMP variable binding list. Otherwise, an extra SNMP Get Request is issued with "sysUpTime" as the only element in the variable binding list. This new "sysUpTime" is called "agent's current sysUpTime". The timestamp in the last CMIS response is then calculated as follows: initial contact time + (agent's current sysUpTime - agent's initial sysUpTime). This approach eliminates the inaccuracy caused by network delay between the ISO/Internet proxy and Internet agent, and gives the ISO/CCITT manager a more accurate indication of when the operation was actually performed by the Internet agent (rather than the time that the response processed by the ISO/Internet proxy). However, in order to convert the sysUpTime, which is the time ticks since the system was last re-initialized, to the CMIS event time, the proxy must be made aware of every reinitialization of the Internet agents. Although each Internet agent generates a Trap when it first comes up, there is no guarantee that the proxy will receive this Trap. Therefore, this method may also be inaccurate. 4.3 Derivation of SNMP Request Parameters 4.3.1 SNMPv2 Party and Context Parameters The SNMPv2 source/destination party and context parameters shall be derived from the values in the privileged attribute certificate (PAC) passed in the access control parameter of the incoming ACSE or CMIS request. If no incoming access control parameter is received, the proxy shall use the default context and parties in the snmpSecurityParameter object instance contained by the cmipsnmpProxyAgent. If no default applies, the operation shall be rejected by the proxy with an access denied error. 4.3.2 SNMPv1 Community String Parameter The SNMPv1 community string parameter shall be derived from the value in the privileged attribute certificate(PAC) passed in the access control parameter of the ACSE or CMIS request. If no incoming access control parameter is received, the proxy shall use the default community string in the snmpSecurityParameter object instance contained by the cmipsnmpProxyAgent. If no default applies, the operation shall be rejected by the proxy with an access denied error. Chang Expires November 29, 1993 Page 29 Draft ISO/CCITT to Internet Management Proxy 5/26/93 4.3.3 Internet Agent Transport Address For SNMPv2, the proxy uses the value of the destination party identifier, derived according to the procedures in 4.3.1, to look up the transport address in an entry of the partyTable. For SNMPv1, the Internet agent transport address shall be derived from the associated transport address in the table of cmipsnmpProxyAgent entries. The cmipsnmpProxyAgent is the one which has the same systemId as the attribute value within the RDN of the system object provided in the AETitle (if local name is used), or the CMIS managed object instance parameter. 4.3.4 SNMP Variable-Bindings Parameter The SNMP variable-bindings list parameter contains a sequence of varBinds, each of which is an (Internet object name, value) pair. For CMIS M-CREATE, M-SET, M-DELETE requests, the Internet object name shall be derived from the DN contained in the CMIP managed object instance parameter, and the attribute identifier provided in the CMIS request attributeIdList or attributeList parameter, using the algorithm defined in [IIMCIMIBTRANS] clause 2.3.1. For M-CREATE and M-SET requests, the Internet object value shall be assigned the attribute value associated with the attributeId from which the Internet object name was derived. For M-GET requests, it is recommended the Internet object value is NULL. For M-DELETE requests, the proxy shall use the delete information as described in the NAME BINDING template behavior defined for the object class. Within the BEHAVIOUR text, the CREATEDELETEATT specifies the Internet object name and CREATEDELETEVALUE specifies the Internet object value which signifies row deletion. 4.4 Derivation Of CMIS Parameters Given the rules specified in this section, and knowledge of the IIMC containment hierarchy (name bindings), the ISO/CCITT {classOID}, {attributeOID}, and distinguished name can be derived from Internet names and the agent identifier. The iimcAutoTrans OID is known to the proxy. It is defined in [IIMCIMIBTRANS]. 4.4.1 Attribute Id Parameter Chang Expires November 29, 1993 Page 30 Draft ISO/CCITT to Internet Management Proxy 5/26/93 Using knowledge of the Internet name structure, and knowledge of valid <internetEntityId>(a) values known to the proxy, the <internetEntityId>(a) and <internet instanceId> may be extracted from the Internet object name. The extraction process is not possible if the valid <internetEntityId>(a) value is not known to the proxy. In that case ,the translation process cannot be performed. The ISO/CCITT attribute identifier is formed as: {iimcAutoTrans <internetEntityId>(a)} 4.4.2 Managed Object Class Parameter In CMIS response, the managed object class parameter can be derived from the proxy's retained information. If actual class is used in the incoming CMIS request, the proxy must derive the object class parameter from the DN in the original CMIS request. The proxy shall compare the attribute value of the last RDN in the CMIS request with all the known ISO/CCITT object classes. The proxy shall assume that object class that has the longest match with the attribute value of the last RDN is the actual object class. If the CMIS request is a scoped request, the object class shall be derived from the retained information. If the Distinguished name is an empty set of RDN, "CCITT Rec. X.660 | ISO/IEC 9834-1 : 1992": root is assumed as the object class. 4.4.3 Managed Object Instance Parameter The managed object instance value (the base managed object's DN) is retained by the proxy during processing of the CMIS request. However, for DNs other than the base managed object instance, the following steps shall be taken to derive the subordinate RDNs. i) The value of the internetClassId naming attribute associated with the object class, may be formed as: {iimcAutoTrans <internetEntityId>(c) <internet instanceId>} ii) The internetClassId value, and the internetClass OID are used to form the final RDN for the object's DN. Assume that the object class was able to be determined using the procedures of 4.4.2. The sequence of other RDNs for the DN may be determined as follows. Use knowledge of the containment hierarchy defined by name bindings, and the Internet agent's identifier. The object class's name binding may be identified as that name binding which contains the object class OID as its final component, in accordance with the name binding Chang Expires November 29, 1993 Page 31 Draft ISO/CCITT to Internet Management Proxy 5/26/93 registration procedures defined in [IIMCIMIBTRANS] clause 2.1.3. Use the superior/subordinate relationships in the name bindings to build the DN in reverse, beginning with the final RDN and ending with the RDN for the ISO/CCITT system object. For superior classes that can have only a single instance, the internetClassId value for the object is created by appending the integer zero to the class OID. The agent's identifier is used as the value for the RDN of the ISO/CCITT system object. One case exists for MIBs derived according to [IIMCIMIBTRANS] where it is possible for the superior object class to have multiple instances. This may occur when the subordinate object class was translated as the result of an SNMPv2 AUGMENTS clause and the superior object class is a table entry. In that case, the instance of the superior object class is identified by the same instanceId used to identify the subordinate object, prepended with the superior object's class OID. If the Internet agent's address cannot be determined, then it may not be possible to associate a notification with a specific agent. This may be a problem if multiple Internet agents are associated with the same network address. In such cases, the DN for the cmipsnmpProxy object instance shall be used as the object instance. 4.4.4 EventId Parameter The eventId parameter shall be the OID assigned the internetAlarm as defined in [IIMCIMIBTRANS]. 4.4.5 InternetAlarm ProbableCause Parameter The internetAlarm notification probableCause parameter shall be derived as defined in [IIMCIMIBTRANS] clause 3.2.5. Internet traps/notifications are registered using the OID corresponding to the value of the Internet snmpTrapOID object defined in [RFC1450]. For SNMPv1 Trap PDUs, the snmpTrapOID is derived as stated in the SNMPv1/SNMPv2 Coexistence document [RFC1452] clause 4.1.2 (2). That definition is repeated below: "... if the value of the generic-trap field is 'enterpriseSpecific' then the value used is the concatenation of the enterprise field from the trap PDU with additional sub- identifiers, '0', and the value of the specific-trap field." For notifications defined according to the SNMPv2 SMI, the probableCause is determined by either the snmpTrapOID.0 or snmpEventID.i, which is contained in the second variable binding of the Trap or InformRequest, respectively. Chang Expires November 29, 1993 Page 32 Draft ISO/CCITT to Internet Management Proxy 5/26/93 Only the "globalValue" (i.e., OID form) of the probableCause syntax shall be used. 4.4.6 InternetAlarm AttributeIdentifier List The following process shall be followed for each variable in the variable-bindings, excluding the first two variable- bindings. The name portion of the variable binding shall be converted to an ISO/CCITT attributeId using the procedure specified in section 4.4.1. The converted ISO/CCITT attributeId shall be placed in the attributeIdList. 4.4.7 InternetAlarm ObjectInstanceList The following process shall be followed for each variable in the variable-bindings, excluding the first two variable- bindings. The name portion of the variable binding shall be converted to an ISO/CCITT object instance name using the procedures specified in section 4.4.3. The converted ISO/CCITT object instance name shall be placed in the object instance list. If the proxy cannot determine the object instance name (e.g., because the Internet agent's identifier cannot be determined), then the objectInstanceList parameter shall not be included in the internetAlarm. 4.4.8 InternetAlarm InternetTrapInfo Parameter The following process shall be followed for each variable in the variable-bindings. The name portion of the variable binding shall be converted to an ISO/CCITT object instance name using the procedures specified in section 4.4.3. The converted ISO/CCITT object instance name shall be placed in the objectInstance field of the internetTrapInfo parameter. If the Internet agent's identifier cannot be determined, or the <internetEntityId>(a) is unknown to the proxy, then the object instance name cannot be determined and the objectInstance field shall not be included in the internetTrapInfo parameter, but shall be included in the unknownVarBindList parameter. 4.4.9 InternetAlarm UnknownVarBindList Parameter If the proxy cannot determine the attributeId for a variable binding (i.e., because the <internetEntityId>(a)portion of the Chang Expires November 29, 1993 Page 33 Draft ISO/CCITT to Internet Management Proxy 5/26/93 Internet object name is not known to the proxy), then that variable binding shall be included in the unknownVarBindList parameter. 4.4.10 InternetAlarm PerceivedSeverity Parameter The proxy cannot determine the perceivedSeverity for the translated SNMP Trap without specific knowledge of the Trap. Therefore, the proxy always assumes "indeterminate" for all the CMIS M-EVENT-REPORTs generated as a result of SNMP Traps. However, a proxy can build in some local knowledge of the SNMP Traps and assign different perceivedSeverity values based on its local knowledge. Such local knowledge is not within the scope of this document. 4.4.11 InternetAlarm TransportDomain Parameter For SNMPv2 Traps, the transportDomain parameter may be determined by using the one of the party identifier parameters associated with the Trap. The partyEntry object identified by the party identifier contains the partyDomain attribute. For either SNMPv1, or SNMPv2 Traps, knowledge of the transport protocol used may be provided to the proxy. Alternatively, if the transport address can be determined, the proxy can determine the transport protocol from the format of the address. The proxy may then be able to determine the appropriate transportDomain value from local knowledge of the OIDs registered for different transport domains. 4.4.12 InternetAlarm TransportAddress Parameter See section 4.3.3 for possible ways to determine the transport address. 4.4.13 InternetAlarm AccessControl Parameter The access control parameter shall be assigned the community string or party identifiers associated with the SNMP Trap. 5 Error Message Translation 5.1 Translating SNMP Error Messages SNMP error responses received by the ISO/Internet proxy are translated to CMIS error responses and sent back to the ISO/CCITT manager. The following sections provides a mapping for SNMP error messages to CMIS error responses. 5.1.1 tooBig If the SNMP error "tooBig" is received, the ISO/Internet proxy should try to break the SNMP Request into smaller requests and Chang Expires November 29, 1993 Page 34 Draft ISO/CCITT to Internet Management Proxy 5/26/93 resend the requests. If it is not feasible to break the request to any smaller request, and this error occurs, the CMIS error response "Complexity limitation" should be returned to the ISO/CCITT manager. 5.1.2 noSuchName If the SNMP error "noSuchName" occurs when an attribute is queried as part of a CMIS Filter evaluation, then the filterItem will be evaluated as FALSE. In order to check if an object exists, all the object class's attributes should be queried until at least one attribute's existence is verified. If none of the attributes exist, and the object is the base managed object, then a "NoSuchObjectInstance" CMIS error response should be returned. If the object exists and the SNMP "noSuchName" error occurs when attempting to read or modify an attribute, a CMIS "No Such Attribute" error response should be returned to the ISO/CCITT manager. If the ISO/Internet proxy maintains correct schema information and the Internet agent is a conforming agent, an Internet object's attributes should either all exist or none exist. In order to make the ISO/Internet proxy a practical solution, the preceding error situation is included in order to deal with a non-conforming Internet agent. 5.1.3 badValue If the SNMP error "badValue" is returned for an SNMP Get Request, then a "processing failure" CMIS error response should be returned to the ISO/CCITT manager. In the ProcessingFailure parameter of the CMIS error response, the errorId should be "snmpBadValue", and the errorInfo should be the variable binding identified by the error-index. If the badValue error occurs during an SNMP Set Request to fulfill a CMIS M-DELETE request, a "processing failure" CMIS error response should be returned. In the ProcessingFailure parameter, the errorId should be " cannotDelete" and the errorInfo should be the variable binding that is identified by the error-index. 5.1.4 readOnly The proxy should never receive an SNMP readOnly error from an SNMPv1 agent. If this error is received, a "processing failure" CMIS error response should be returned to the ISO/CCITT manager. In the processingFailure parameter, the errorId should be "snmpReadOnly" and the errorInfo should be the variable binding that is identified by the error-index. Chang Expires November 29, 1993 Page 35 Draft ISO/CCITT to Internet Management Proxy 5/26/93 For SNMPv2, if the SNMP error "readOnly" occurs when checking for the existence of a base object, a "processingfailure" CMIS error response should be returned to the ISO/CCITT manager. In the ProcessingFailure parameter of the CMIS error response, the errorId should be "snmpReadOnly", and the errorInfo should be the variable binding identified by the error-index. If the error occurs when deleting the object, then the deleteErrorInfo field in the response shall be set to "accessDenied". 5.1.5 genErr If the SNMP error "genErr" occurs, the "ProcessingFailure" CMIS error response should be returned to ISO/CCITT manager. If the entry exists, scoping continues; otherwise, scoping terminates. In the ProcessingFailure parameter of the CMIS error response, the errorId should be "snmpGenErr". There are additional error messages in SNMPv2. Most of the errors are defined for the Set Request. Since a Set Request may be originated when processing a CMIP M-SET request, an M- CREATE request or an M-DELETE request, the proxy must ensure each error code is translated to the one which is most compatible with the original CMIS request. In addition, the proxy must ensure the selected error value is compatible with the use of other parameters such as scoping, filtering, synchronization and multiple linked reply. 5.1.6 noAccess This error indicates the variable binding's name specifies a variable which is not accessible by an SNMP Set Request. This error should be mapped to the CMIS "accessDenied" error. 5.1.7 wrongType This error indicates the variable binding's value field of an SNMP Set Request specified a type which is inconsistent with that required for the variable. This error may be mapped to the CMIS "invalidAttributeValue" error. 5.1.8 wrongLength This error indicates the variable binding's value field of an SNMP Set Request specifies, according to the ASN.1 language, a length which is inconsistent with that required for the variable. If the original CMIS request is M-CREATE or M-SET, the CMIS error "InvalidAttributeValue" shall be returned. If the original CMIS request is M-DELETE, the CMIS "processing failure" error shall be returned. 5.1.9 wrongEncoding Chang Expires November 29, 1993 Page 36 Draft ISO/CCITT to Internet Management Proxy 5/26/93 This error is used to indicate the variable binding's value field of an SNMP Set Request contains an ASN.1 encoding which is inconsistent with that field's ASN.1 tag. This error should be mapped to the CMIS "processingFailure" error. 5.1.10 wrongValue This error indicates the variable binding's value field in an SNMP Set Request specifies a value which could under no circumstances be assigned to the variable. This error should be mapped to the CMIS "invalidAttributeValue" error. 5.1.11 noCreation This error is generated when an SNMP Set Request variable binding name specified a variable which does not exist and could not ever be created. This error should be mapped to the CMIS "invalidObjectInstance" error. 5.1.12 inconsistentValue This error indicates that an SNMP Set Request variable binding value field specified a value that could under other circumstances be assigned to the variable, but is presently inconsistent. If the SNMP Set Request was generated as a result of a CMIS M-CREATE or M-SET operation, the error should be mapped to the CMIS "invalidAttributeValue" error. If the SNMP Set Request was generated as a result of CMIS M- DELETE operation, the error may be mapped to the CMIS "processingfailure" error. 5.1.13 resourceUnavailable This error indicates that the assignment of a value by an SNMP Set Request requires the allocation of a resource which is presently unavailable. This error may be mapped to the CMIS "resourceLimitation" error. 5.1.14 commitFailed When performing an SNMP Set Request, the Internet agent must ensure all variable assignments occur atomically. If any of the assignments fail, an SNMP "commitFailed" error is returned. If the original CMIS request is a "best effort" request, the proxy should either retry the failed variable assignments by sending multiple SNMP Set Requests, or return a CMIS setListError with a "processingfailure" error. Chang Expires November 29, 1993 Page 37 Draft ISO/CCITT to Internet Management Proxy 5/26/93 5.1.15 undoFailed When performing an SNMP Set Request, the Internet agent must ensure all variable assignments occur atomically. If any of the assignments fail, the agent should undo all the assignments. An SNMP "undoFailed" error is returned when the agent cannot undo all the assignments. CMIS does not have any error value equivalent to this. The CMIS "processing failure" error must be returned. 5.1.16 authorizationError This error indicates that an SNMP Request has been discarded because the authorization context used in the request does not allow the PDU type. This error is mapped to the CMIS "accessDenied" error. 5.1.17 notWritable The "notWritable" error is used to indicate that an SNMP Set Request is trying to modify the value of a variable which is not modifiable, no matter what new value is specified. This error shall be mapped to the CMIS "invalidOperation" error. 5.2 CMIS Processing Failure There are many error scenarios in which the error cannot be mapped to a specific CMIS error. In this case, the "processing failure" CMIS error response should be reported back to the ISO/CCITT manager. In order to provide the ISO/CCITT manager with a better description of the error, the specificErrorInfo field in ProcessingFailure is used to record the cause of the problem. The following object identifiers are defined: snmpTooBig OBJECT IDENTIFIER ::= { iimcErrors 0 } snmpBadValue OBJECT IDENTIFIER ::= { iimcErrors 1 } snmpReadOnly OBJECT IDENTIFIER ::= { iimcErrors 2 } snmpGenErr OBJECT IDENTIFIER ::= { iimcErrors 3 } noResponse OBJECT IDENTIFIER ::= { iimcErrors 4 } cannotDelete OBJECT IDENTIFIER ::= { iimcErrors 5 } notImplemented OBJECT IDENTIFIER ::= { iimcErrors 6 } wrongLength OBJECT IDENTIFIER ::= { iimcErrors 7 } wrongEncoding OBJECT IDENTIFIER ::= { iimcErrors 8 } Chang Expires November 29, 1993 Page 38 Draft ISO/CCITT to Internet Management Proxy 5/26/93 where the errInfo parameter depends on the value of errorId: errorId errInfo ------- ------- snmpTooBig VarBindList snmpBadValue VarBind snmpReadOnly OBJECT IDENTIFIER cannotDelete VarBind notImplemented INTEGER { transport(0), authenticationProtocol(1), privacyProtocol(2) } 6 ISO/CCITT Systems Management Functions ISO/CCITT systems management standards include a set of Systems Management Function specifications. An ISO/Internet proxy may choose to support some or all of these systems management functions. This section provides some of the modeling approaches which may be used in supporting ISO/CCITT systems management functions. 6.1 Event Report Management Function The ISO/CCITT Event Report Management Function [ISO10164-5] defines an Event Forwarding Discriminator (EFD) managed object which allows an ISO/CCITT manager to control the forwarding and processing of potential event reports by an ISO/CCITT agent. The Event Report Management Function maybe supported by an ISO/Internet proxy to allow the ISO/CCITT manager to control where and how Internet Traps and Inform Requests may be forwarded. Since all Internet Traps and Inform Requests are translated by the proxy and are forwarded to their destinations by the proxy, EFD managed objects are best supported by the proxy as local objects. Upon receiving a CMIS M-CREATE request for an EFD, the proxy creates the EFD object instance according to the specified name binding. Once created, the EFD is used by the proxy to determine which CMIS M-EVENT-REPORTs are to be forwarded to a particular destination during a specified time period. 6.2 Log Control Function The ISO/CCITT Log Control Function [ISO10164-6] defines a Log managed object which allows control and monitoring of a log and the retrieval of its log records. If the Log managed object is supported, Internet Traps and Inform Requests may be logged according to a predefined criteria. Chang Expires November 29, 1993 Page 39 Draft ISO/CCITT to Internet Management Proxy 5/26/93 Since only notifications are logged and these are constructed by the proxy, the Log managed object can be defined as a local object of a proxy. Upon receiving a CMIS M-CREATE request for a Log object, the proxy creates the Log instance according to the specified name binding. Once created, the Log is used by the proxy to process the received Traps and Inform Requests (and local notifications) for logging. An InternetAlarmRecord managed object class is defined in [IIMCIMIBTRANS]. 6.3 Scope of the EFD and Log EFD and Log objects can be created under either the remote system or the proxy system objects. EFD and Log object instance behaviour is different depending on its position in the containment tree. "containment object" | +-remote system | |- EFD (for remote events) | |- Log - Log Record (for remote events) | | | |_ translated MIB group class subtree(s) | +-proxy system -- cmipsnmpProxy -cmipsnmpProxyAgent | |- EFD (for proxy events) |- Log - Log Record (for proxy events) | |- EFD (for all events) |- Log - Log Record (for all events) EFD and Log objects contained by the remote system object shall process only those events generated by the objects known to each Internet agent (i.e., objects contained by the same remote system object). EFD and Log objects contained by a proxy system object with the instance name "ProxyOnly" shall process only those events emitted from the object instances contained by the proxy system. Any other EFD or Log object contained by the proxy system shall apply to any event (including all events generated by any object). If an EFD or Log is created under the proxy system using automatic instance naming, the proxy shall choose a name other than the name "ProxyOnly". 7 ISO/CCITT-Internet Proxy MIB Chang Expires November 29, 1993 Page 40 Draft ISO/CCITT to Internet Management Proxy 5/26/93 The ISO/CCITT-Internet Proxy MIB defines a set of objects for specifying the information that is needed for both community- based and party-based SNMP management on a per Internet agent basis. The containment hierarchy and other introductory information regarding this Proxy MIB can be found in section 2.3. The GDMO templates and ASN.1 modules are included here in one section to facilitate automated processing. Comments and subsection headers are included in the form of ASN.1 comments, i.e., preceded by "--". This document (IIMCPROXY) is allocated the following registration identifier for purposes of referencing material contained herein. iimcIIMCProxy OBJECT IDENTIFIER ::= {iimcManagementDocMan 3} 7.1 Proxy MIB GDMO Templates -- 7.1.1 Proxy MIB Managed Object Classes cmipsnmpProxyAgent MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992":top; CHARACTERIZED BY cmipsnmpProxyAgentPkg PACKAGE BEHAVIOUR cmipsnmpProxyAgentPkgBehaviour BEHAVIOUR DEFINED AS !This managed object class is used to represent an Internet agent in the proxy MIB. Each agent that the proxy manages is represented by an instance of this object class. The cmipsnmpProxyAgentId attribute contains the administratively-assigned name of the managed system that contains the Internet agent. Usually this is an Internet Domain Name. This attribute value shall be determined by the manager when the object is created. The managementProtocol attribute specifies the Internet management protocol used by the proxy to manage devices. It shall be the OID indicating SNMPv1, SNMPv2, or some other protocol. This attribute is assigned a value (an OID) by the manager that is appropriate for the Internet agent. The supportedMIBs attribute identifies the set of GDMO documents that describe the MIBs that the Internet agent supports. The ISO/CCITT manager may Chang Expires November 29, 1993 Page 41 Draft ISO/CCITT to Internet Management Proxy 5/26/93 add elements to or remove elements from this attribute. Two object instances shall be created by the proxy automatically when an instance of the cmipsnmpProxyAgent class is created. One is the system object that represents the Internet agent. The other is the "OP1 Library Vol. 4":capabilityObject as defined by [NMF006]. The accessControlEnforcement attribute indicates where access control is applied: at the Internet agent, the ISO/Internet proxy, or both. The accessControlMechanism attribute indicates whether no access control, Internet access control as specified in [RFC1446], or ISO/CCITT access control as specified in [ISO10164-9] is to be used. The default is no access control. The administrativeState attribute is used to suspend or resume the proxy activity relative to the Internet agent. It is the same as the administrativeState attribute defined in [ISO10165-2]. The "unlocked" state means that proxy must continue to perform, or resume performing, proxy activities on behalf of the Internet agent. The "locked" state means that the proxy must not perform, or suspend performing, proxy activities on behalf of the Internet agent. !;; ATTRIBUTES cmipsnmpProxyAgentId GET, {iimcManagementDoc 1}:transportAddress GET-REPLACE, managementProtocol REPLACE-WITH-DEFAULT GET, supportedMIBs GET-REPLACE ADD-REMOVE, accessControlEnforcement GET-REPLACE, accessControlMechanism DEFAULT VALUE IimcProxyASN1.noAccessControl GET-REPLACE, "Rec. X.721 | ISO/IEC 10165-2 : 1992": administrativeState GET-REPLACE;;; REGISTERED AS { iimcProxyObjectClass 1 }; cmipsnmpProxy MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" : top; CHARACTERIZED BY cmipsnmpProxyPkg PACKAGE BEHAVIOUR Chang Expires November 29, 1993 Page 42 Draft ISO/CCITT to Internet Management Proxy 5/26/93 cmipsnmpProxyPkgBehaviour BEHAVIOUR DEFINED AS !This managed object class is used to contain objects that represent an Internet agent in the proxy MIB. The internetAlarm shall be emitted by this object class when the application level source of the SNMP Trap or Inform Request cannot be determined. The address field of the internetAlarm shall be set to the network address associated with the SNMP Trap or Inform Request.!;; ATTRIBUTES {iimcManagementDocMan 1}:internetClassId GET; NOTIFICATIONS {iimcManagementDocMan 1}:internetAlarm;;; REGISTERED AS {iimcProxyObjectClass 2}; snmpSecurityParameter MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" : top; CHARACTERIZED BY defaultSecurityParameterPkg PACKAGE BEHAVIOUR defaultSecurityParameterPkgBehaviour BEHAVIOUR DEFINED AS ! This object instance contains the default security parameter that is used only when such AccessControl field is not received during association establishment.!;; ATTRIBUTES "iimcManagementDoc 1":internetClassId GET, snmpSecurity GET-REPLACE ADD-REMOVE ;;; REGISTERED AS {iimcProxyObjectClass 3}; -- 7.1.2 Proxy MIB Attributes accessControlEnforcement ATTRIBUTE WITH ATTRIBUTE SYNTAX IimcProxyASN1.AccessControlEnforcement; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR accessControlEnforcementBehaviour BEHAVIOUR DEFINED AS !The accessControlEnforcement attribute indicates where access control is applied: Internet agent, proxy, or both.!;; REGISTERED AS {iimcProxyAttributeID 1 }; accessControlMechanism ATTRIBUTE Chang Expires November 29, 1993 Page 43 Draft ISO/CCITT to Internet Management Proxy 5/26/93 WITH ATTRIBUTE SYNTAX IimcProxyASN1.AccessControlMechanism; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR accessControlMechanismBehaviour BEHAVIOUR DEFINED AS !The accessControlMechanism attribute indicates which access control is to be applied at the proxy device. The mechanism may be no access control, the internet access control as defined in [RFC1446] or one of the ISO access control mechanisms as defined in [ISO10164-9].!;; REGISTERED AS {iimcProxyAttributeID 2 }; cmipsnmpProxyAgentId ATTRIBUTE WITH ATTRIBUTE SYNTAX IimcProxyASN1.DistinguishedName; MATCHES FOR EQUALITY; BEHAVIOUR cmipsnmpProxyAgentIdBehaviour BEHAVIOUR DEFINED AS !This is the naming attribute for the cmipsnmpProxyAgent object class. This attribute will name the system which represents the proxied device.!;; REGISTERED AS {iimcProxyAttributeID 3 }; managementProtocol ATTRIBUTE WITH ATTRIBUTE SYNTAX IimcProxyASN1.ObjectIdentifier; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR managementProtocolBehaviour BEHAVIOUR DEFINED AS !This attributes specifies the Internet management protocol used for proxy to managed devices. It shall have a value of either SNMPv1 or SNMPv2.!;; REGISTERED AS {iimcProxyAttributeID 4 }; supportedMIBs ATTRIBUTE WITH ATTRIBUTE SYNTAX IimcProxyASN1.SupportedMIBs; MATCHES FOR EQUALITY, SET-COMPARISON, SET-INTERSECTION; BEHAVIOUR supportedMIBsBehaviour BEHAVIOUR DEFINED AS !This attribute specifies the set of Internet OIDs of registered MIBs that the agent supports.!;; REGISTERED AS {iimcProxyAttributeID 5 }; snmpSecurity ATTRIBUTE WITH ATTRIBUTE SYNTAX IimcProxyASN1.SnmpSecurity; MATCHES FOR EQUALITY; Chang Expires November 29, 1993 Page 44 Draft ISO/CCITT to Internet Management Proxy 5/26/93 BEHAVIOUR snmpSecurityBehaviour BEHAVIOUR DEFINED AS !This attribute specifies the default values to be used when other AccessControl values are not available (i.e., when no AccessControl fields are received during association establishment or on a given CMIS operation).!;; REGISTERED AS {iimcProxyAttributeID 7 }; -- 7.1.3 Proxy MIB Name Bindings cmipsnmpProxy-systemNB NAME BINDING SUBORDINATE OBJECT CLASS cmipsnmpProxy; NAMED BY SUPERIOR OBJECT CLASS "Rec. X.721 | ISO/IEC 10165-2 : 1992": system; WITH ATTRIBUTE {iimcManagementDoc 1}:internetClassId; BEHAVIOUR cmipsnmpProxy-systemNBBehaviour BEHAVIOUR DEFINED AS !There is only one object instance of this object class in the proxy and this managed object instance should be created by the proxy process. It is not creatable and deletable via CMIP management operation.!;; REGISTERED AS {iimcProxyNameBinding 1}; cmipsnmpProxyAgent-cmipsnmpProxyNB NAME BINDING SUBORDINATE OBJECT CLASS cmipsnmpProxyAgent; NAMED BY SUPERIOR OBJECT CLASS cmipsnmpProxy; WITH ATTRIBUTE cmipsnmpProxyAgentId; BEHAVIOUR cmipsnmpProxyAgent-cmipsnmpProxyNBBehaviour BEHAVIOUR DEFINED AS !This managed object may be created and deleted either by management action, or by local action, of the proxy. A side effect of the creation/deletion of this object shall be the creation/deletion of the ISO system managed object associated with the Internet agent. The cmipsnmpProxyAgentId contains the DN of the proxied device.!;; CREATE WITH-REFERENCE-OBJECT; DELETE; REGISTERED AS {iimcProxyNameBinding 2}; snmpSecurityParameter-cmipsnmpProxyNB NAME BINDING SUBORDINATE OBJECT CLASS snmpSecurityParameter; NAMED BY SUPERIOR OBJECT CLASS cmipsnmpProxy; WITH ATTRIBUTE {iimcManagementDoc 1}:internetClassId; Chang Expires November 29, 1993 Page 45 Draft ISO/CCITT to Internet Management Proxy 5/26/93 BEHAVIOUR snmpSecurityParameter-cmipsnmpProxyNBBehaviour BEHAVIOUR DEFINED AS !This managed object is created automatically when the containing cmipsnmpProxy object is created.!;; REGISTERED AS {iimcProxyNameBinding 3}; 7.2 Proxy MIB ASN.1 Module IimcProxyASN1 {iimcManagementModMan 3} DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS iimcManagementProxy, iimcManagementModMan, iimcManagementDocMan, iimcIIMCProxy FROM IimcAssignedOIDs {iimcManagementModMan 1} ObjectIdentifier, AccessControlInfo FROM IimcCommonDef (iimcManagementModMan 2} DistinguishedName FROM InformationFramework { joint-iso-ccitt ds(5) modules (1) informationFramework (1) }; -- for ISO/CCITT-Internet proxy specific extension iimcProxySpecificExtension OBJECT IDENTIFIER ::={iimcManagementProxy specificExtension(0)} -- for ISO/CCITT-Internet proxy object class iimcProxyObjectClass OBJECT IDENTIFIER ::={iimcManagementProxy managedObjectClass(3)} -- for ISO/CCITT-Internet proxy package iimcProxyObjectClass OBJECT IDENTIFIER ::={iimcManagementProxy package(4)} -- for ISO/CCITT-Internet proxy attribute iimcProxyAttributeID OBJECT IDENTIFIER ::={iimcManagementProxy attribute(7)} -- for ISO/CCITT-Internet proxy name bindings iimcProxyNameBinding OBJECT IDENTIFIER ::={iimcManagementProxy nameBinding(6)} -- SNMP Protocol version iimcSnmpProtocol OBJECT IDENTIFIER ::= { iimcProxySpecificExtension snmpProtocol(1) } -- the OID for SNMPv1 snmpV1 OBJECT IDENTIFIER ::= {iimcSnmpProtocol snmpV1(1) } -- the OID for SNMPv2 snmpV2 OBJECT IDENTIFIER ::= {iimcSnmpProtocol snmpV2(1) } Chang Expires November 29, 1993 Page 46 Draft ISO/CCITT to Internet Management Proxy 5/26/93 -- the OID for IIMC errors iimcErrors OBJECT IDENTIFIER ::= { iimcProxySpecificExtension errors(2) } snmpTooBig OBJECT IDENTIFIER ::= { iimcErrors 0 } snmpBadValue OBJECT IDENTIFIER ::= { iimcErrors 1 } snmpReadOnly OBJECT IDENTIFIER ::= { iimcErrors 2 } snmpGenErr OBJECT IDENTIFIER ::= { iimcErrors 3 } noResponse OBJECT IDENTIFIER ::= { iimcErrors 4 } cannotDelete OBJECT IDENTIFIER ::= { iimcErrors 5 } notImplemented OBJECT IDENTIFIER ::= { iimcErrors 6 } wrongLength OBJECT IDENTIFIER ::= { iimcErrors 7 } wrongEncoding OBJECT IDENTIFIER ::= { iimcErrors 8 } AccessControlUsed ::= INTEGER { noAccessControl (0), internet (1), iso (2)} AccessControlEnforcement ::= INTEGER { agent (0), proxy (1), both (2)} SupportedMIBs ::= SET OF CHOICE { oid OBJECT IDENTIFIER, ps PrintableString } ErrInfo ::= INTEGER { transport(0), authenticationProtocol(1), privacyProtocol(2) } SnmpSecurity ::= SEQUENCE { snmpOperation SnmpOpType, snmpSecurityInfo AccessControlInfo } SnmpOpType ::= ENUMERATED { getReqPdu(0), getNextReqPdu(1), getRespPdu(2), setReqPdu(3), trapPdu(4), getBulk(5), informReq(6) } END Chang Expires November 29, 1993 Page 47 Draft ISO/CCITT to Internet Management Proxy 5/26/93 8 Conformance Requirements 8.1 Management Communication Requirements An implementation of the ISO/Internet proxy shall satisfy the following management communication requirements. - The ISO/Internet proxy shall conform to ISO/CCITT CMIP in the agent role, as specified by [ISO9596-1] and [ISO9595], and profiled by AOM12 [ISO11183-1,2]. - The ISO/Internet proxy shall conform to either Internet SNMPv1 or SNMPv2 in the manager role, as specified by [RFC1157] or [RFC1448]. - The ISO/Internet proxy shall conform to all mandatory security requirements specified by [IIMCSEC] for each supported version of SNMP (SNMPv1 and/or SNMPv2). If proxy supports only SNMPv1, then enforcement of access control and Party MIB support is optional. 8.2 Management Function Requirements An implementation of the ISO/Internet proxy shall satisfy the following management function requirements. - The ISO/Internet proxy may optionally conform to ISO/CCITT system management functions in the agent role, as specified by either [ISO10164-5] or [ISO10164-6], and profiled by AOM221 [ISO12060-4] or AOM231 [ISO12060-5]. 8.3 Management Information Requirements An implementation of the ISO/Internet proxy shall satisfy the following management information requirements. - The ISO/Internet proxy shall support the "system" object specified by [ISO10165-2], in the agent role. - The ISO/Internet proxy shall support the translated MIB- II "internetSystem" object specified by [IIMCMIB-II], in the manager role. - The ISO/Internet proxy shall support the IIMC Proxy MIB definitions specified by section 7 of this document, in the agent role. - The ISO/Internet proxy shall support the IIMC Party MIB definitions specified by [IIMCSEC], in the agent role. Chang Expires November 29, 1993 Page 48 Draft ISO/CCITT to Internet Management Proxy 5/26/93 - The ISO/Internet proxy shall support the Internet Party MIB definitions specified by [RFC1447], in the manager role. - The ISO/Internet proxy shall support one or more translated MIBs, derived in accordance with the procedures specified by [IIMCIMIBTRANS]. For each supported MIB, the ISO/CCITT GDMO translation shall be supported in the agent role, and the Internet MIB shall be supported in the manager role. - The ISO/Internet proxy shall comply with the information models specified by [ISO10165-1,4] and either [RFC1155], [RFC1212], or [RFC1442]. - The ISO/Internet proxy may optionally support the "OP1 Library Vol.4":capabilityObject" specified by [NMF006], in the agent role. 8.4 Service Emulation Requirements An ISO/Internet proxy implementation that claims conformance to this specification must state the level of CMIS service emulation that it supports. Two levels are defined: a) a basic proxy which emulates CMIS kernel services, plus support for scoped CMIS Get; and b) an enhanced proxy which emulates all CMIS services, including scoping and filtering on all applicable CMIS services. As noted in section 8.1, the proxy requires support for the Enhanced Management Communications Profile AOM12. That is, the proxy is required to support CMIP kernel, multiple object selection, filtering, and multiple reply functional units. However, a basic proxy is not required to request the filtering functional unit. Furthermore, a basic proxy is not required to carry out scoping for CMIS services other than M- GET, and returns the CMIS error "complexity limitation" for any other CMIS service request which contains a Scope parameter value not equal to "base object alone". These limitations do not apply to the enhanced proxy, which is required to carry out both scoping and filtering for all CMIS service requests. Editor's Note: [Deletion of Conceptual Table Translation, as proposed in Appendix B of [IIMCIMIBTRANS], would require the basic proxy also to support an M-GET Filter value consisting of a single AVA on the objectClass attributeId.] 9 Acknowledgments The following individuals have contributed to this effort. Chang Expires November 29, 1993 Page 49 Draft ISO/CCITT to Internet Management Proxy 5/26/93 Bob Aronoff - NIST Jon Biggar - NetLabs Mary Brady - NIST April Chang - NetLabs Ken Chapman - Stratus Computer Inc. Alice Chen - Boeing Christopher Crowell - Cabletron Systems Jock Embry - Opening Technologies Ian Emsley - Bull S.A Paul Golick - IBM Ulrich Gremmelmaier - University of Stuttgart Pramod Kalyanasundaram - University of Delaware Ken Hunter - Hewlett-Packard Lee LaBarre - The MITRE Corporation David Liu - Northern Telecom Jim MacLeod - U S West Reece Markowsky - OSIWare Subrata Mazumdar - IBM Keith McCloghrie - Hughes LAN Systems Owen Newnan - U S West Steve Ng - MPR Teltech Yasuhiro Ohara - NTT Jong-Tae Park - KyungPook National University George Pavlou - University College of London Lisa Phifer - Bellcore Jim Reilly - Technical Rsch Ctr of Finland Tom Rutt - AT&T Adarsh Sethi - University of Delaware Raj Sirsikar - University of Delaware Baltej Singh - OSIWare Mark Smith - Hewlett-Packard Einar Stefferud - Network Management Associates Mark Sylor - Digital Hector Trevino - Bellcore Huy Truong - Tandem Al Vincent - U S West Dean Voiss - NetLabs David Waitzman - BBN Graham Wisdom - Timeplex Yoshi Yamashita - NKK Corporation Chang Expires November 29, 1993 Page 50 Draft ISO/CCITT to Internet Management Proxy 5/26/93 References [ISO7498-4] ISO/IEC IS 7498-4, Information Processing Systems - Open Systems Interconnection -Basic Reference Model Part 4 - Management Framework, 1989. [ISO8824] ISO/IEC 8824: Information Technology - Open System Interconnection - Specification of Abstract Syntax Notation One (ASN.1),1990. [ISO8825] ISO/IEC 8825: Information Technology - Open System Interconnection-Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1),1990. [ISO9595] ISO/IEC 9595, Information Technology - Open System Interconnection - Common Management Information Service Definition, 1991. [ISO9596-1] ISO/IEC 9596-1, Information Technology - Open Systems Interconnection - Common Management Information Protocol - Part 1: Specification, 1991. [ISO10164-5] ISO/IEC 10164-5: Information Technology - Open Systems Interconnection - Systems Management - Part 5: Event Report Management Function, 1991. [ISO10164-6] ISO/IEC 10164-6: Information Technology - Open Systems Interconnection - Systems Management - Part 6: Log Control Function, 1991. [ISO10164-9] ISO DIS 10164-9, Information Processing Systems - Open Systems Interconnection - Structure of Management Information - Part 9: Objects and Attributes for Access Control, ISO/IEC JTC1/SC21/N7661, March, 1993. [ISO10165-1] ISO/IEC 10165-1: Information Technology - Open Systems Interconnection - Structure of Management Information - Part 1: Management Information Model, 1991. [ISO10165-2] ISO/IEC 10165-2: Information Technology - Open Systems Interconnection - Structure of Management Information - Part 2: Definition of Management Information, 1992. [ISO10165-4] ISO/IEC 10165-4: Information Technology - Open Systems Interconnection - Structure of Management Information - Part 4: Guidelines for the Definition of Managed Objects, 1991. [ISO11183-1] ISO/IEC ISP 11183-1, Information Technology - International Standardized Profiles AOM1n OSI Management - Management Communications Protocols - Part 1: Specification of Chang Expires November 29, 1993 Page 51 Draft ISO/CCITT to Internet Management Proxy 5/26/93 ACSE, Presentation, and Session Protocols for the use by ROSE and CMISE, May 1992. [ISO11183-2] ISO/IEC ISP 11183-2, Information Technology - International Standardized Profiles AOM1n OSI Management - Management Communications Protocols - Part 2: AOM12 - Enhanced Management Communications, June 1992. [ISO12060-4] ISO/IEC DISP 12060-4, Information Technology - International Standardized Profiles AOM2n OSI Management - Management Functions - Part 4: AOM221 - General Event Report Management, July 1992. [ISO12060-5] ISO/IEC DISP 12060-5, Information Technology - International Standardized Profiles AOM2n OSI Management - Management Functions - Part 5: AOM231 - General Log Control, July 1992. [RFC1155] RFC1155, M. Rose and K. McCloghrie, Structure and Identification of Management Information for TCP/IP based internets, May 1990. [RFC1157] RFC1157, J.D. Case, M.S. Fedor, M.L. Schoffstall,C. Davin, Simple Network Management Protocol (SNMP), May 1990. [RFC1212] RFC1212, M. Rose, K. McCloghrie - Editors, Concise MIB Definitions, March 1991. [RFC1213] RFC1213, K. McCloghrie and M. Rose - Editors, Management Information Base for Network Management of TCP/IP- basedinternets: MIB-II, March 1991. [RFC1441] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser, Introduction to version 2 of the Internet-standard Network Management Framework, April 1993. [RFC1442] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser, Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2), April 1993. [RFC1446] J.M. Galvin, K. McCloghrie, J.R. Davin, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), April 1993. [RFC1447] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser, Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2), April 1993. [RFC1448] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser, Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2), April 1993. Chang Expires November 29, 1993 Page 52 Draft ISO/CCITT to Internet Management Proxy 5/26/93 [RFC1450] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser, Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2), April 1993. [RFC1452] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser, Coexistence between version 1 and version 2 of the Internet Network Management Framework, April 1993. [IIMCIMIBTRANS] ISO/CCITT and Internet Management Coexistence (IIMC): Translation of Internet MIBs to ISO/CCITT GDMO MIBs, Draft 2, May 1993. [IIMCMIB-II] ISO/CCITT and Internet Management Coexistence (IIMC): Translation of Internet MIB-II (RFC1213) to ISO/CCITT GDMO MIB, Draft 2, May 1993. [IIMCSEC] ISO/CCITT and Internet Management Coexistence (IIMC): ISO/CCITT to Internet Management Security, Draft 2, May 1993. [IIMCOMIBTRANS] ISO/CCITT and Internet Management Coexistence (IIMC): Translation of ISO/CCITT GDMO MIBs to Internet MIBs, Draft 2, May 1993. [NMF006] Network Management Forum: Forum 006, OMNIPoint 1 Library Volume 4, Issue 1.0, August, 1992. [NMFTR107] NM Forum and X/Open, ISO/CCITT and Internet Management: Coexistence and Interworking Strategy, Issue 1.0, October, 1992. Chang Expires November 29, 1993 Page 53 Draft ISO/CCITT to Internet Management Proxy 5/26/93 Appendix A (Normative) Managed Object Conformance Statements (MOCS) Editor's Note: [This section will be filled in prior to publication. When completed, this section will contain a tabular representation of the managed object classes, attributes, notifications, and name bindings defined in this document. The format of these proforma tables will be as defined by ISO/IEC 10165-6.] Chang Expires November 29, 1993 Page 54 Draft ISO/CCITT to Internet Management Proxy 5/26/93 Appendix B (Informative) Example Operation Operation: CMIS M-GET request Object class: Internet MIB-II ip Object instance:{systemTitle = "NetLabs"/internetClassId = ip} Scope: 2nd level down Filter: ipRouteType == indirect Attribute id list: ipRouteDest Example Internet MIB-II ipRouteEntries: ipRouteDest ipRouteType Other object types 192.95.93.1 direct 192.95.93.2 indirect 192.95.93.3 invalid 192.95.93.4 other 192.95.93.5 indirect (end of the table) The following sections show an example of how the ISO/Internet proxy fulfills the above CMIS M-GET request based on the example Internet MIB-II ipRouteEntries. 1. Check the existence of the base object The ISO/Internet proxy issues an SNMP GetNext Request. GetNextRequest { ip } GetResponse { ipForwarding = 1 } If the get is successful, the ISO/Internet proxy would have verified that the base object exists. 2. Managed object selection Based on the name binding definition, the following object classes are found in the "object class group": a) ipAddrEntry b) ipRouteEntry c) ipNetToMediaEntry For each object in the "object class group", the object instances may be retrieved via SNMP GetNext Requests. a) ipAddrEntry: The definition for this object class does not contain the attribute specified in the filter (ipRouteType), therefore the ISO/Internet proxy concludes that there are no object instances with ipAddrEntryobject class in the scope. Chang Expires November 29, 1993 Page 55 Draft ISO/CCITT to Internet Management Proxy 5/26/93 b) ipRouteEntry: The definition for this object class contains the attribute specified in the filter (ipRouteType),therefore the ISO/Internet proxy issues SNMP GetNext Requests to retrieve the object instances. The SNMP requests issued and the responses received would be as follows: GetNextRequest {ipRouteDest, ipRouteType} GetResponse {ipRouteDest.192.95.93.1 = 192.95.93.1, ipRouteType.192.95.93.1 = direct} GetNextRequest {ipRouteDest.192.95.93.1, ipRouteType.192.95.93.1} GetResponse {ipRouteDest.192.95.93.2 = 192.95.93.2, ipRouteType.192.95.93.2 = indirect} GetNextRequest {ipRouteDest.192.95.93.2, ipRouteType.192.95.93.2} GetResponse {ipRouteDest.192.95.93.3 = 192.95.93.3, ipRouteType.192.95.93.3 = invalid} GetNextRequest {ipRouteDest.192.95.93.3, ipRouteType.192.95.93.3} GetResponse {ipRouteDest.192.95.93.4 = 192.95.93.4, ipRouteType.192.95.93.4 = other} GetNextRequest {ipRouteDest.192.95.93.4, ipRouteType.192.95.93.4} GetResponse {ipRouteDest.192.95.93.5 = 192.95.93.5, ipRouteType.192.95.93.5 = indirect} GetNextRequest {ipRouteDest.192.95.93.5, ipRouteType.192.95.93.5} GetResponse {ipRouteIfIndex = 5, ipRouteProto = 1} c) ipNetToMediaEntry: The definition for this object class does not contain the attribute specified in the filter (ipRouteType), therefore the ISO/Internet proxy concludes that there are no object instances with ipNetToMediaEntry object class in the scope. Chang Expires November 29, 1993 Page 56 Draft ISO/CCITT to Internet Management Proxy 5/26/93 There are a set of five object instances in the scope. After the filter is applied to these five object instances, there are only two object instances left on which the CMIS M-GET operation is performed. 3. Form the response The following CMIS responses should be formed and sent back to the ISO/CCITT manager CMIS M-GET Response (first linked reply PDU): Object class: ipRouteEntry Object instance:/systemTitle = { "NetLabs"/ internetClassId = ip/ internetClassId = ipRouteTable/ internetClassId = ipRouteEntry.192.95.93.2 } Attribute list: ipRouteDest = 192.95.93.2 CMIS M-GET Response (second linked reply PDU): Object class: ipRouteEntry Object instance: { /systemTitle = "NetLabs"/ internetClassId = ip/ internetClassId = ipRouteTable/ internetClassId = ipRouteEntry.192.95.93.5 } Attribute list: ipRouteDest = 192.95.93.5 CMIS M-GET Response (final empty response PDU) {internetClassId = ip } INTERNET DRAFT - Expires November 29, 1993 Chang Expires November 29, 1993 Page 57